Secnora INC

09/02/2026

🛡️ 𝗖𝗹𝗼𝘂𝗱 𝗔𝗣𝗜 𝗮𝗻𝗱 𝗧𝗲𝗹𝗲𝗺𝗲𝘁𝗿𝘆 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 𝗳𝗼𝗿 𝗠𝗼𝗱𝗲𝗿𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀

Your observability stack can become an attack surface too.

Modern cloud architectures rely heavily on APIs to connect services and telemetry pipelines to monitor them. While the external application layer often gets the most hardening focus, internal API routes and telemetry backends can become hidden attack vectors.

🚪 𝗘𝗻𝗳𝗼𝗿𝗰𝗶𝗻𝗴 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝘀
An API gateway provides an important defense layer before traffic reaches internal services. Request-size limits, schema validation and rate limiting can reject malformed or excessive requests early. However, valid schemas can still contain malicious values, so these controls should be combined with context-appropriate input validation, sanitization and parameterized queries where applicable.

🔒 𝗦𝗲𝗰𝘂𝗿𝗶𝗻𝗴 𝗧𝗲𝗹𝗲𝗺𝗲𝘁𝗿𝘆 𝗧𝗿𝗮𝗻𝘀𝗽𝗼𝗿𝘁
Telemetry agents continuously send traces, metrics and logs across network boundaries. Mutual TLS (mTLS) authenticates both endpoints and protects telemetry in transit, helping prevent unauthorized systems from connecting to the pipeline. But an authenticated agent can still be compromised, making backend-side validation and anomaly detection important for identifying manipulated telemetry.

🧹 𝗧𝗿𝗮𝗰𝗲 𝗗𝗮𝘁𝗮 𝗦𝗮𝗻𝗶𝘁𝗶𝘇𝗮𝘁𝗶𝗼𝗻
Traces often contain detailed application context, which can unintentionally expose session tokens, credentials or personal data. Filtering and redacting sensitive attributes at the telemetry collector before they reach centralized storage reduces the risk of accidental exposure and supports data-minimization and compliance objectives such as GDPR and PCI DSS.

🛑 𝗣𝗿𝗲𝘃𝗲𝗻𝘁𝗶𝗻𝗴 𝗟𝗼𝗴 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻
Attackers can manipulate trace context headers or input fields to introduce misleading content into logs and traces. If downstream dashboards or SIEM platforms process this data without proper validation and sanitization, it can generate false alerts, distort investigations or bury genuine attacks in noise. Sanitizing incoming telemetry helps preserve the integrity of observability data.

🔑 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Protect internal APIs and observability infrastructure as part of the security boundary
• Combine gateway controls with context-specific input protections
• Use mTLS, backend validation and anomaly detection for telemetry security
• Redact sensitive data before it reaches centralized storage
• Validate telemetry inputs to keep security data trustworthy and actionable

⚠️ Protecting these observability pipelines helps keep monitoring data reliable and prevents them from becoming unintended channels for data exposure or manipulation.

08/31/2026

🔓 𝗧𝗲𝗿𝗺𝗶𝗻𝗮𝗹𝗙𝗶𝘅 𝗨𝘀𝗲𝘀 𝗙𝗮𝗸𝗲 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲 𝗖𝗔𝗣𝗧𝗖𝗛𝗔𝘀 𝘁𝗼 𝗗𝗲𝗽𝗹𝗼𝘆 𝗮 𝗥𝗲𝘃𝗲𝗿𝘀𝗲-𝗧𝘂𝗻𝗻𝗲𝗹 𝗕𝗮𝗰𝗸𝗱𝗼𝗼𝗿

Microsoft has published details of a new ClickFix variant dubbed "TerminalFix" which tricks users into pasting a malicious command straight into Windows Terminal or PowerShell rather than the Run dialog. Traditional ClickFix lures route victims to the Run dialog. TerminalFix uses the same social-engineering hook but redirects them to Terminal or PowerShell instead, making it far more likely that longer, multi-line scripts run without breaking.

🎭 𝗧𝗵𝗲 𝗦𝗼𝗰𝗶𝗮𝗹 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗧𝗿𝗮𝗽
The attack begins on compromised websites showing a fake Cloudflare Turnstile CAPTCHA overlay. Visitors are guided to copy a "verification" command and paste it into Terminal or PowerShell as instructed.

💻 𝗗𝗟𝗟 𝗦𝗶𝗱𝗲𝗹𝗼𝗮𝗱𝗶𝗻𝗴 𝗮𝗻𝗱 𝗦𝘁𝗲𝗴𝗮𝗻𝗼𝗴𝗿𝗮𝗽𝗵𝘆
Once pasted, the command downloads a ZIP archive containing a legitimate signed Windows binary and a malicious DLL. The trusted binary loads the malicious DLL through DLL sideloading, so ex*****on begins inside a process that already looks clean. From there, the malware downloads PNG images and reconstructs hidden executable and DLL fragments from the pixel data itself, a steganography technique that keeps the payload looking harmless in transit.

🕵️ 𝗘𝘅𝘁𝗲𝗻𝘀𝗶𝘃𝗲 𝗔𝗰𝘁𝗶𝘃𝗲 𝗗𝗶𝗿𝗲𝗰𝘁𝗼𝗿𝘆 𝗥𝗲𝗰𝗼𝗻𝗻𝗮𝗶𝘀𝘀𝗮𝗻𝗰𝗲
With persistence set through both a registry run key and a scheduled task, the malware moves into reconnaissance, covering domain trust enumeration, domain admin discovery and ping sweeps of servers such as domain controllers, databases and backup systems. The scripts even carry English, Spanish and German locale variants, suggesting the operators are prepared to operate across a range of environments.

🕸️ 𝗥𝗲𝘃𝗲𝗿𝘀𝗲 𝗧𝘂𝗻𝗻𝗲𝗹 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁
The final stage deploys a custom Python-based implant that opens a reverse WebSocket tunnel back to attacker infrastructure over TLS. This gives the attacker proxy-level access to reach other systems inside the network, effectively turning the compromised endpoint into a potential pivot point for lateral movement. Microsoft notes it did not observe the downstream lateral-movement stage in this specific analyzed chain.

🎯 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• TerminalFix succeeds by getting a user to manually paste and run a command, not by breaking a technical control.
• DLL sideloading combined with image-based steganography makes the payload harder to catch with traditional detection.
• The campaign methodically maps Active Directory to find high-value internal targets.
• A compromised endpoint can become a network pivot point through the encrypted reverse tunnel.
• The strongest defense here is awareness, not a new tool. If a "security verification" ever asks you to open a terminal and paste something, that's the moment to pause and check with your security team.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://www.microsoft.com/en-us/security/blog/2026/08/28/terminalfix-campaign-deploys-reverse-tunnel-through-multistage-intrusion/

08/28/2026

🛡️ 𝗖𝗔𝗦𝗘 𝗦𝗧𝗨𝗗𝗬: 𝗖𝗘𝗩𝗔 𝗟𝗼𝗴𝗶𝘀𝘁𝗶𝗰𝘀 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁

Global supply chain provider, CEVA Logistics security incident highlights the technical complexities of identity security and downstream partner exposure. Public disclosures and internal communications indicate that multiple user accounts were compromised, resulting in data extraction across internal workforce directories and partner environments.

🏢 𝗔𝘁𝘁𝗮𝗰𝗸 𝗦𝘂𝗿𝗳𝗮𝗰𝗲 𝗮𝗻𝗱 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗘𝘅𝗽𝗼𝘀𝘂𝗿𝗲
Current and former CEVA employees were notified, via an internal email, that an unauthorised party had accessed and copied their personal and work-related records. Disclosed exposure categories include national ID numbers (BSN), ID copies, home addresses, bank details, pension information and salary data. Not every category applied to every individual, and the total number of employees affected has not been determined.

🔗 𝗗𝗼𝘄𝗻𝘀𝘁𝗿𝗲𝗮𝗺 𝗣𝗮𝗿𝘁𝗻𝗲𝗿 𝗘𝘅𝗽𝗼𝘀𝘂𝗿𝗲
Because logistics providers operate deep integrations with enterprise clients, the exposure extended into the systems of the companies CEVA serves. Companies relying on CEVA for fulfilment, including bol, De Bijenkorf, ING, Ajax, Ace & Tate and Valve, confirmed that customer names, addresses, phone numbers and emails tied to shipping orders were potentially exposed. Valve separately notified recent Steam hardware buyers.

🛡️ 𝗦𝗰𝗼𝗽𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁
The operational impact spans at least eight CEVA warehouses across Europe, with the intrusion believed to have begun around 29 July. CEVA says the affected systems sit within its European contract logistics operations, not its global network. Dutch authorities confirmed receiving breach reports from twelve organisations connected to the incident.

🛠️ 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗺𝗲𝗻𝘁 𝗮𝗻𝗱 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲
CEVA deactivated the compromised user accounts and activated its security protocols after detection. The incident has been reported to the Dutch data protection authority and external cybersecurity experts continue to assist with the investigation.

🎯 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Enforce least-privilege access and routine credential rotation across identity providers.
• Reduce data exposure through data minimisation and defined retention limits, especially for HR and partner-facing systems.
• Build credential revocation playbooks that can be triggered the moment unauthorised account activity is detected.
• Maintain visibility into where partner data actually lives, including file shares, HR systems and downstream integrations, since partner breaches expose your customers even when your own systems are untouched.

08/27/2026

🚨 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟳𝟯𝟬𝟰𝟭 - 𝗖𝗩𝗦𝗦 𝗦𝗰𝗼𝗿𝗲 𝟵.𝟰 (𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹): 𝗧𝗵𝗲 𝗣𝗗𝗙 𝗧𝗵𝗮𝘁 𝗧𝗿𝗮𝘃𝗲𝗹𝘀 𝗪𝗶𝘁𝗵 𝗜𝘁𝘀 𝗢𝘄𝗻 𝗥𝗖𝗘

Five unescaped annotation fields turned a routine PDF into a path to remote code ex*****on.

In SiYuan's desktop client, five annotation fields (node ID, relations, mode, type and color) get written to disk with zero validation, then interpolated straight into the DOM via insertAdjacentHTML with no escaping. Two lines below, the exact same function handles a sixth field correctly, using setAttribute instead of a raw template string.

The gap between those two lines is the whole vulnerability.

Because the app runs with nodeIntegration and contextIsolation turned off in its Electron shell, that unescaped field doesn't stay a browser-scoped XSS bug. It has a direct line to require('child_process') and because the payload lives in a sidecar file that travels with sync, export and import, sharing a notebook is enough to carry it along. This vulnerability is identified by Shirshak Roy, Security Engineer at SECNORA.

📌 CVSS Score: 9.4 (Critical)
📌 Affected: SiYuan kernel, master and dev branches
📌 Fixed in: v3.7.4

If you're running SiYuan, update to v3.7.4 or later before opening notebooks or PDFs from sources you don't fully control.

🔗 𝗥𝗲𝗮𝗱 𝗳𝘂𝗹𝗹 𝗯𝗹𝗼𝗴: https://secnora.com/blog/cve-2026-73041-siyuan-pdf-annotation-rce/

CVE-2026-73041 exposes a critical SiYuan flaw where malicious PDF annotations can trigger stored XSS and potentially lead to RCE. Explore the attack chain, impact, and fix.

08/25/2026

🔒 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟲𝟯𝟭𝟳𝟴: 𝗢𝗻𝘆𝘅 𝗖𝘂𝗿𝗮𝘁𝗼𝗿-𝗦𝗰𝗼𝗽𝗲 𝗜𝗗𝗢𝗥 𝗧𝘂𝗿𝗻𝘀 𝗚𝗿𝗼𝘂𝗽 𝗠𝗲𝗺𝗯𝗲𝗿𝘀𝗵𝗶𝗽 𝗜𝗻𝘁𝗼 𝗮 𝗕𝗮𝗰𝗸𝗱𝗼𝗼𝗿

Onyx Enterprise Edition assigns curators scoped admin rights over only the groups they curate. Two endpoints didn't enforce that.

CVE-2026-63178 is a curator-scope IDOR (CWE-639). PATCH /manage/admin/user-group/{id} and POST /manage/admin/user-group/{id}/add-users verified the caller was a curator, never that they curated that specific group.

Any curator could rewrite the membership of any group in the deployment, including adding themselves. Since Onyx builds document-retrieval ACLs from live group membership, that self-add translated directly into another team's document access, no separate bug in the search layer required.

The correct scope check already existed elsewhere in the same codebase, for curator-relationship updates and document-set creation. It just wasn't wired into these two routes.

📌 Affected: Onyx Enterprise Edition < 4.3.0
📌 Access required: Authenticated Curator or Global Curator account
📌 CVSS Score: 6.5 (Medium)
📌 Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
📌 Fixed in: v4.3.0

Reproduced on self-hosted Onyx v4.0.7 (Enterprise Edition), a curator scoped only to one group was able to modify a second group outside their scope through both endpoints. A basic-role user run through the same request confirmed the route-level role check was otherwise intact. This vulnerability is identified by Shirshak Roy, security engineer at Secnora.

If you're running Onyx Enterprise Edition, upgrade and audit curator activity logs for group IDs outside each curator's assigned scope before assuming it wasn't used.

🔗 𝗥𝗲𝗮𝗱 𝗳𝘂𝗹𝗹 𝗯𝗹𝗼𝗴: https://secnora.com/blog/cve-2026-63178-onyx-curator-scope-idor/

08/24/2026

🛡️ 𝗪𝗵𝘆 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝗮𝗻𝗱 𝗔𝗣𝗜 𝗞𝗲𝘆𝘀 𝗮𝗿𝗲 𝗤𝘂𝗶𝗲𝘁𝗹𝘆 𝗕𝗲𝗰𝗼𝗺𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗕𝗶𝗴𝗴𝗲𝘀𝘁 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗥𝗶𝘀𝗸

Identity security conversations still focus heavily on humans through MFA, SSO, conditional access and phishing simulations. These controls matter but non-human identities often receive less attention.

Walk through any modern environment and the identity count tells a different story. Service accounts, API keys, OAuth tokens, CI/CD credentials and machine-to-machine connections have quietly become a significant part of the identity landscape, often without anyone tracking the total.

Ownership is rarely assigned. Reviews happen even less and because monitoring is largely tuned to human behaviour, unusual activity from a machine identity can go unnoticed for longer than it should.

A few recurring patterns are worth examining
🔹 Provisioned for a project, forgotten after launch. The integration ships, the deadline passes, the key stays active with the same broad scope it was given on day one.
🔹 Tied to someone who's since left. The account keeps working long after the person who requested it is gone because offboarding never touched the credentials they created.
🔹 Shared across environments to save time. One key running staging and production started as a shortcut under deadline pressure and rarely gets revisited once the pressure lifts.
🔹 Granted admin-level scope for a task that only needed read access. Broad permissions are quicker to approve and narrowing them later falls through the cracks.

Negligence is the easy explanation. A lifecycle gap is the accurate one. A credential gets created for a legitimate purpose but the controls around its ownership, scope, usage and retirement rarely evolve with the environment it operates in.

For security teams, four questions are worth asking of every service account and API key in production:
👤 Who owns it? Map every credential to a specific team or accountable individual, rather than a shared login nobody claims.
🔐 What can it access? Ensure permissions still match the task the credential was created for.
🔎 Where is it being used? Monitor usage across systems and environments to identify activity outside expected patterns.
⏳ When does it expire? Define clear rotation, review and retirement requirements rather than leaving credentials open-ended.

The goal is not to eliminate service accounts or API keys. Modern infrastructure depends on them. The goal is to make them visible, attributable, appropriately scoped and governed throughout their lifecycle.

🎯 Machine identities need the same lifecycle discipline as human identities.

08/21/2026

🚨 𝗖𝗮𝘀𝗲 𝗦𝘁𝘂𝗱𝘆: 𝗥𝗶𝗻𝗴𝗖𝗲𝗻𝘁𝗿𝗮𝗹 𝗦𝗼𝗰𝗶𝗮𝗹 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗕𝗿𝗲𝗮𝗰𝗵

"ShinyHunters" has claimed responsibility for a data exposure at RingCentral affecting ~1.6 million accounts, following a sophisticated social engineering campaign the company confirmed in July 2026. RingCentral stated the core platform remained fully operational throughout.

🕵️‍♂️ 𝗧𝗵𝗿𝗲𝗮𝘁 𝗢𝘃𝗲𝗿𝘃𝗶𝗲𝘄 𝗮𝗻𝗱 𝗩𝗲𝗰𝘁𝗼𝗿
RingCentral's advisory identifies it as a social engineering campaign, with no CVE, patch or affected product version tied to the disclosure. Threat actors are increasingly targeting the human layer when perimeter and application defences are otherwise well hardened and this incident tracks that broader shift.

📂 𝗦𝗰𝗼𝗽𝗲 𝗼𝗳 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻
Data claimed to be exposed includes:
• Unique email addresses
• Full names
• Phone numbers
• Physical addresses

Passwords and highly sensitive financial data do not appear to be part of this specific exposure, limiting the immediate risk of direct account takeovers without further credential stuffing or phishing attempts.

🛡️ 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲 𝗮𝗻𝗱 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗺𝗲𝗻𝘁
RingCentral stopped the unauthorized activity upon detection and engaged a third-party forensic firm to investigate. The company reports no new unauthorized activity since remediation, a sign of effective containment.

🏢 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗶𝘁𝘆 𝗮𝗻𝗱 𝗜𝗺𝗽𝗮𝗰𝘁
The core RingCentral platform saw no outages, and services continued without disruption throughout the incident. RingCentral is contacting affected customers directly, with impact limited to a portion of its customer base.

📌 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Social engineering remains a formidable vector against well-secured cloud platforms.
• Fast detection and isolation prevent lateral movement into core systems.
• Bringing in external forensic experts early strengthens containment and gives an objective read on scope.
• Continuous platform uptime during an active incident points to strong architectural segmentation.
• Direct, transparent communication with affected customers reduces confusion and reputational fallout during exposure events.

🎯 The human layer tends to get tested far less often than the technical one, cases like this are a reminder why that gap matters.

08/20/2026

🔒 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟲𝟴𝟱𝟴𝟰: 𝗦𝗶𝗬𝘂𝗮𝗻 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗕𝘆𝗽𝗮𝘀𝘀 𝗘𝘅𝗽𝗼𝘀𝗲𝗱 𝗣𝗮𝘀𝘀𝘄𝗼𝗿𝗱-𝗣𝗿𝗼𝘁𝗲𝗰𝘁𝗲𝗱 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝘀

A password-protected document on SiYuan v3.7.2 and earlier could be read in full by an anonymous user, no login, no password required, if publish mode was enabled.

That is CVE-2026-68584.

The primary content endpoint enforced the password correctly. Six alternate endpoints that returned the same underlying content didn't, because the access check was implemented per-endpoint instead of once in the shared render path.

🔎 𝗥𝗼𝗼𝘁 𝗰𝗮𝘂𝘀𝗲
The document's ID is public by design (protected docs are listed, just not readable). A search endpoint leaked internal heading block IDs it should have withheld. From there, an unprotected content endpoint returned the full document.

📌 CVE-2026-68584
📌 CVSS Score: 8.6 (High)
📌 Affected: SiYuan v3.7.2 and earlier
📌 Fixed: v3.7.3

If you're running SiYuan in publish mode:
➡️ Check your version
➡️ Check whether publish mode is on
➡️ Check which documents are set to protected or private

Upgrade to v3.7.3+ and rotate the publish password on anything that was protected or private during the exposure window. The vulnerability was identified by Shirshak Roy, Security Engineer at SECNORA.

💡𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗧𝗲𝗮𝗺𝘀
A single unprotected endpoint sharing a render path with a protected one can undo the entire access model. Auditing content-returning endpoints as a set, not one at a time, is what catches this before it ships.

𝗥𝗲𝗮𝗱 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻: https://secnora.com/blog/cve-2026-68584-siyuan-authentication-bypass/

08/18/2026

🚨 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟲𝟵𝟬𝟴𝟰: 𝗨𝗻𝗮𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗲𝗱 𝗔𝗿𝗯𝗶𝘁𝗿𝗮𝗿𝘆 𝗦𝗤𝗟 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝘃𝗶𝗮 𝘀𝗲𝗮𝗿𝗰𝗵𝗘𝗺𝗯𝗲𝗱𝗕𝗹𝗼𝗰𝗸

Send the same SQL statement to two SiYuan endpoints as an anonymous reader. One returns "administrator privileges required". The other returns HTTP 200 with your query result.

That single difference is CVE-2026-69084.

The vulnerable endpoint "𝘀𝗲𝗮𝗿𝗰𝗵𝗘𝗺𝗯𝗲𝗱𝗕𝗹𝗼𝗰𝗸" pulled a full SQL statement straight out of the request body and ran it on SiYuan's live database. The statement was passed to the database without statement validation, privilege checks or read-only restrictions.

What makes CVE-2026-69084 stand out:

🔹 CVSS 3.1 score of 10.0 (Critical), the maximum possible rating
🔹 Reachable with a publish RoleReader token, or without credentials when Publish.Auth.Enable was disabled
🔹 The database handle was fully read-write, with no query-only restriction in place
🔹 SiYuan's SQLite driver executes stacked statements, so a single request could chain a read with a write
🔹 A response filter did exist, but it ran only after the query had already executed, so it filtered output rather than preventing database-side effects

While "/𝗮𝗽𝗶/𝗾𝘂𝗲𝗿𝘆/𝘀𝗾𝗹" already had stronger controls around statement ex*****on, "𝘀𝗲𝗮𝗿𝗰𝗵𝗘𝗺𝗯𝗲𝗱𝗕𝗹𝗼𝗰𝗸" lacked the same protections, leaving the endpoint exposed in SiYuan v3.7.2 and earlier. The issue was fixed in v3.7.3 and was identified by Shirshak Roy, Security Engineer at SECNORA.

🔗 Read the full technical breakdown: https://secnora.com/blog/cve-2026-69084/

08/17/2026

🚨𝗖𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹 𝗧𝗵𝗲𝗳𝘁 𝗖𝗮𝗺𝗽𝗮𝗶𝗴𝗻 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝘀 𝗔𝘇𝘂𝗿𝗲 𝗧𝗲𝗻𝗮𝗻𝘁 𝗗𝗶𝗿𝗲𝗰𝘁𝗼𝗿𝗶𝗲𝘀 𝗮𝘁 𝗠𝗰𝗗𝗼𝗻𝗮𝗹𝗱'𝘀, 𝗧𝗖𝗦 𝗮𝗻𝗱 𝗩𝗼𝗱𝗮𝗳𝗼𝗻𝗲

A threat actor known as "TheHatman" is selling internal employee directories from at least nine global enterprises, including McDonald's, Vodafone, TCS, HCL Technologies, Kyndryl, IHG, Gap Inc., Hexaware and Wyndham Hotels, on dark web forums. The data was reportedly extracted directly from Azure and Entra portals using compromised credentials.

📊 𝗦𝗰𝗮𝗹𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲
The exposure spans IT services, telecommunications, retail, hospitality, and logistics. Corporate email domains and field structures in the leaked samples align precisely with standard Azure directory exports, lending the data high credibility. Notable exposures reportedly include:
• McDonald's Corporation over 1.7 million records
• TCS over 800,000 records
• Vodafone over 425,000 records
• HCL Technologies over 250,000 records
• Kyndryl, IHG and Gap Inc. ranging from tens to hundreds of thousands respectively

🔍 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗕𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗼𝗳 𝘁𝗵𝗲 𝗘𝘅𝗳𝗶𝗹𝘁𝗿𝗮𝘁𝗲𝗱 𝗗𝗮𝘁𝗮
Analysis of the leaked tenant dumps reveals foundational corporate directory attributes that provide a comprehensive view of internal organisational layouts:
• Core Identity: Full names, active corporate emails, tenant-specific domains, phone numbers and physical addresses
• Organisational Structure: Employee IDs, job titles, department names, manager details and direct report mappings
• Access and Privileges: User group memberships, service accounts and highly privileged account records such as Global Administrator listings

🦠 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗜𝗻𝘁𝗿𝘂𝘀𝗶𝗼𝗻 𝗩𝗲𝗰𝘁𝗼𝗿𝘀
The exact attack vector remains under investigation. The pattern points to targeted credential exploitation rather than a platform-wide Azure vulnerability, since only large enterprises appear affected. In at least one case, a machine compromised by infostealer malware held direct access to a Kyndryl Azure AD account, linking initial access to stolen session tokens or credentials.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
Exposed directory data gives attackers a roadmap for privilege escalation and Business Email Compromise:
• Monitor for Infostealer Activity: Track compromised employee and third-party credentials tied to infostealer malware.
• Strengthen Access Controls: Enforce MFA across all tenant portals to limit session token theft.
• Protect High-Value Accounts: Monitor activity around service accounts and Global Administrator listings.
• Prepare for Targeted Phishing: Exposed reporting lines and manager details make spear-phishing attempts more convincing.

📩 Strong MFA enforcement paired with session token and credential monitoring at the endpoint level remains one of the most effective ways to limit cloud tenant exposure.