Secnora INC

10/28/2026

🚨 𝗧𝗵𝗲 𝗕𝘂𝗴 𝗜𝘀𝗻’𝘁 𝗔𝗹𝘄𝗮𝘆𝘀 𝗶𝗻 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽: 𝗪𝗵𝗮𝘁 𝗣𝗛𝗣𝟮𝗦𝗵𝗲𝗹𝗹 𝗮𝗻𝗱 𝗡𝗼𝗱𝗲𝟮𝗦𝗵𝗲𝗹𝗹 𝗥𝗲𝘃𝗲𝗮𝗹 𝗔𝗯𝗼𝘂𝘁 𝗥𝘂𝗻𝘁𝗶𝗺𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆

Your SAST is green, your auth middleware is well tested and your dependencies are pinned. Yet unauthenticated requests can reach vulnerable native code. In one confirmed PHP2Shell path on Apache mod_php, that meant RCE during request parsing, before application code ran. Node2Shell exposes a different risk in Brotli decompression.

🧠 𝗪𝗵𝗮𝘁 𝗦𝘂𝗿𝘃𝗶𝘃𝗲𝘀 𝘁𝗵𝗲 𝗥𝗲𝗾𝘂𝗲𝘀𝘁?
In CVE-2026-109619, PHP worker globals can retain pointers after request-owned memory is freed. A later request handled by the same worker can act on them. Session upload progress is one confirmed attack path and PHP warns that other variants exist.

CVE-2026-109618 is another lifecycle failure. An OOM error triggers longjmp() while request memory is partly initialised and shutdown can then process invalid state. RCE was demonstrated in Apache mod_php during parsing, before application code. PHP's analysis says PHP-FPM is susceptible but no complete exploit was shown for this flaw.

⚙️ 𝗪𝗵𝗲𝗻 𝗮 𝗙𝗼𝗿𝗺𝗮𝘁 𝗘𝗿𝗿𝗼𝗿 𝗕𝗲𝗰𝗼𝗺𝗲𝘀 𝗮 𝗠𝗲𝗺𝗼𝗿𝘆 𝗘𝗿𝗿𝗼𝗿
Node2Shell (CVE-2026-111497, also called HTTP2Shell) is a flaw in Brotli decompression. An invalid block switch was treated as a need for more input rather than a format error, so the decoder kept writing into an eight-byte buffer. That out-of-bounds write can lead to a crash, memory disclosure or code ex*****on.

Express 5 body parsers, once enabled, decompress Brotli request bodies by default. On PHP Windows builds, cURL can reach the same library when response decompression is enabled.

🔎 𝗧𝗵𝗲 𝗔𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻 𝗧𝗵𝗮𝘁 𝗕𝗿𝗲𝗮𝗸𝘀
These are different flaws with different prerequisites. Yet each has a moment when processing carries on with state whose validity has changed: freed request memory, partially initialised cleanup data or a malformed compressed stream.

🛠️ 𝗧𝗿𝗮𝗰𝗲 𝘁𝗵𝗲 𝗥𝘂𝗻𝘁𝗶𝗺𝗲, 𝗡𝗼𝘁 𝗝𝘂𝘀𝘁 𝘁𝗵𝗲 𝗖𝗼𝗱𝗲𝗯𝗮𝘀𝗲
• Inventory PHP and Node.js executables, SAPIs and bundled Brotli libraries, including container images.
• Trace untrusted multipart data and compressed request or response bodies to actual processing paths.
• Examine OOM handling, shutdown and cross-request worker state.
• Apply fixed PHP (8.2.35/8.3.36/8.4.27/8.5.12, Windows -1 rebuilds) and Node.js (22.23.4/24.22.1/26.12.1), update Brotli to 1.0.10, 1.1.1 or 1.2.1, then restart or redeploy.
• Plan upgrades for end of life lines. PHP 7.4 to 8.1 only got source backports, while PHP 7.3 and older and Node.js 25, 23, 20 and older have no fix.

🛡️ Disabling session upload progress in php.ini or the FPM pool can block documented paths before patching and PHP also advises it for the separate CVE-2026-115560. It doesn't replace the update and ini_set() in application code runs too late.

10/27/2026

🔐 𝗟𝗶𝘁𝗲𝗟𝗟𝗠 𝗦𝘂𝗽𝗽𝗹𝘆-𝗖𝗵𝗮𝗶𝗻 𝗔𝘁𝘁𝗮𝗰𝗸: 𝗛𝗼𝘄 𝗮 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗥𝗲𝗹𝗲𝗮𝘀𝗲 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗪𝗮𝘀 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱

Only a hyphen distinguishes BerriAI/litellm from Berri-AI/litellm. One is LiteLLM's legitimate repository. The other is the attacker-controlled fork its v1.107.0 release was built from.

The official v1.107.0 source tag contained no malicious files. Still, LiteLLM's established release pipeline signed and published compromised artifacts built from this substituted source.

The critical trust decision occurred before signing, when the attacker manipulated which repository the workflow would build.

🔑 𝗙𝗿𝗼𝗺 𝗮𝗻 𝗨𝗻𝗿𝗲𝘃𝗼𝗸𝗲𝗱 𝗞𝗲𝘆 𝘁𝗼 𝗢𝘄𝗻𝗲𝗿-𝗟𝗲𝘃𝗲𝗹 𝗔𝗰𝗰𝗲𝘀𝘀
An Agent Platform master key was inadvertently committed to a public repository in May. The commit was removed but the key remained unrevoked. On 10 October, the attacker used it to query the Agent Platform API, which exposed a GitHub CLI OAuth token associated with a LiteLLM organisation owner's account.

The token was not associated with a service account, had not been scoped down and was already post-2FA. According to LiteLLM, these CLI tokens were not subject to additional GitHub reauthentication for sensitive actions. The attacker then ran temporary CI workflows that sent repository secrets including two maintainers' CLI tokens, to an external endpoint.

⚙️ 𝗛𝗼𝘄 𝘁𝗵𝗲 𝗥𝗲𝗹𝗲𝗮𝘀𝗲 𝗦𝗼𝘂𝗿𝗰𝗲 𝗪𝗮𝘀 𝗥𝗲𝗽𝗹𝗮𝗰𝗲𝗱
In LiteLLM's private project-releaser repository, the attacker modified a workflow to permit an alternative source repository. Branch protection blocked that change when it was pushed with a maintainer's token. With the owner’s token, the attacker disabled those protections and pushed the same change.

The staging workflow was redirected from BerriAI/litellm to Berri-AI/litellm, an attacker-controlled lookalike. LiteLLM had temporarily relaxed its usual release approval process. The owner's token triggered staging and a compromised maintainer token approved the production gate.

The established pipeline then signed and published seven compromised PyPI wheels for v1.107.0, alongside affected Docker Hub and GHCR images.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀 𝗳𝗼𝗿 𝗥𝗲𝗹𝗲𝗮𝘀𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆
• Revoke exposed credentials and limit privileged tokens to the access they need.
• Protect workflow changes and source selection as tightly as release approvals.
• Verify published artifacts against approved repositories and commits and treat release-approver identities as high-value credentials.

Release integrity depends on the provenance of what was built and the authority behind each workflow change.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain

10/22/2026

🔐 𝗧𝗵𝗲 𝗩𝗣𝗡 𝗦𝗲𝘀𝘀𝗶𝗼𝗻 𝗖𝗮𝗻 𝗕𝗲 𝘁𝗵𝗲 𝗜𝗻𝗶𝘁𝗶𝗮𝗹 𝗔𝗰𝗰𝗲𝘀𝘀, 𝗡𝗼𝘁 𝗝𝘂𝘀𝘁 𝘁𝗵𝗲 𝗣𝗮𝘀𝘀𝘄𝗼𝗿𝗱

A VPN login can pass every authentication check and still become the route for unauthorised network activity. The login record describes the authentication event, not the traffic that follows. Once the session is established, the gateway relies on session state to keep granting access and that state is what an attacker can abuse.

🔀 𝗧𝘄𝗼 𝗪𝗮𝘆𝘀 𝗮 𝗟𝗲𝗴𝗶𝘁𝗶𝗺𝗮𝘁𝗲 𝗦𝗲𝘀𝘀𝗶𝗼𝗻 𝗚𝗲𝘁𝘀 𝗔𝗯𝘂𝘀𝗲𝗱
• Stolen authentication material: Some SSL VPN gateways use reusable cookies or tokens. If an attacker obtains valid, replayable material, it can give access without a fresh MFA challenge.
• Compromised endpoint: Malware on an already-connected device can use its existing VPN tunnel to reach whatever that connection is allowed to reach. No stolen cookie is needed because the compromise comes first and the tunnel is how it reaches the network.

These are distinct attack paths. Not every VPN session is replayable. Token validation, cryptographic binding and protocol design determine what an attacker can reuse.

🔎 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 𝗟𝗼𝗴𝗶𝗻 𝗥𝗲𝗰𝗼𝗿𝗱 𝗗𝗼𝗲𝘀 𝗡𝗼𝘁 𝗦𝗵𝗼𝘄
Consider a successful SSO and MFA event followed by unusual SMB, RDP or administrative activity on the user's VPN connection. The authentication record is valid but the activity that follows may not be. That alone does not establish session hijacking, since a gateway can tie traffic to a session but not to the process that generated it, which usually requires endpoint telemetry.

📡 𝗧𝗵𝗿𝗲𝗲 𝗟𝗼𝗴𝘀 𝘁𝗼 𝗖𝗼𝗿𝗿𝗲𝗹𝗮𝘁𝗲
• Identity: Authentication events, MFA method and device context.
• VPN state: Session identifiers, tunnel-assigned IPs, connected endpoints and session termination events.
• Internal activity: Destinations, protocols, access patterns and process-level evidence where available.

If one of the three logs is missing or incomplete, the investigation loses part of the picture. Source IP changes alone are weak signals, since roaming and NAT are normal.

🧪 𝗗𝗼𝗲𝘀 𝗮 𝗣𝗮𝘀𝘀𝘄𝗼𝗿𝗱 𝗥𝗲𝘀𝗲𝘁 𝗞𝗶𝗹𝗹 𝘁𝗵𝗲 𝗦𝗲𝘀𝘀𝗶𝗼𝗻?
Whether an established VPN connection survives a password reset depends on the VPN platform, identity integration and configuration. A controlled test shows the actual behaviour, and testing explicit revocation separately shows the difference. Changing credentials and invalidating authenticated sessions are not equivalent operations.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• MFA shows how a session began, not who is using it now. Monitor and revoke sessions instead of trusting them once.
• Replay and endpoint abuse need different defences, client binding for one and EDR with segmentation for the other.
• Test whether a password reset ends an established VPN session. Do not assume it does.
• Correlate IdP, VPN and EDR logs so unusual activity can be tied to a device and process.

10/20/2026

👤 𝗛𝘂𝗺𝗮𝗻 𝗮𝗽𝗽𝗿𝗼𝘃𝗮𝗹 𝗶𝘀 𝗮 𝘂𝘀𝗲𝗳𝘂𝗹 𝗰𝗼𝗻𝘁𝗿𝗼𝗹 𝗳𝗼𝗿 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀, 𝗯𝘂𝘁 𝗮𝘀 𝗮 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗶𝘁 𝗵𝗮𝘀 𝗹𝗶𝗺𝗶𝘁𝘀

A human clicking "Approve" does not necessarily mean the action being authorised is the action that will execute.

As AI agents which are autonomous gain access to production systems, to cloud infrastructure and to enterprise APIs, human-in-the-loop (HITL) approval is becoming a common form of safeguard since it provides oversight and accountability. A security boundary, on the other hand has a more limited role, it must hold whenever a component behaves in an unexpected way, no matter what context the reviewer was in at that time.

The approval gap can appear in a few places.

A reviewer could end up seeing a natural-language summary rather than the exact details of the operation and the target resources. Since the agent is the one that produces the summary, if untrusted content affects it by means of prompt injection, then it can also influence the approval prompt. OWASP includes prompt injection as item LLM01 in its Top 10 for LLM Applications.

Approvals can also become older or broader. Parameters can change between authorisation and ex*****on and one approval can start further tool calls that receive less scrutiny. The large volume of prompts contributes to the problem even careful reviewers have a limited amount of time available for each decision and this is a matter of system design rather than something that reflects on the people carrying out the reviews.

Approval means more when it is bound to the executed operation, parameters and target included, rather than to the agent's description of its intent.

For security leaders, a few controls can narrow the gap:
🔹 Independent policy enforcement. Checks outside the model validate each tool call against permissions, scope and permitted operations.
🔹 Execution-bound approvals. Sign-off covers the specific action and parameters with revalidation when material details change.
🔹 Least-privilege, short-lived credentials. With sandboxing and egress allow-listing, they limit how far one approved action can reach.
🔹 Audit trails. Linking the request, the context shown and the actual ex*****on gives teams a reliable record after an incident.
🔹 Human approval for high-impact or irreversible actions. Fewer prompts mean each one gets proper attention.

No control completely eliminates all risk and human oversight is still useful for making judgements and understanding the business context, whereas the enforcement of permissions and scope should be incorporated into the system architecture.

For CISOs and security architects, a practical starting point is to document what "Approve" authorises for each agent with production access and which control enforces that limit.

🎯 A human can authorise an action. The system should still enforce what that authorisation permits.

10/19/2026

🚨 𝗚𝗵𝗼𝘀𝘁𝗔𝗰𝘁𝗶𝗼𝗻 𝗖𝗮𝗺𝗽𝗮𝗶𝗴𝗻 𝗨𝘀𝗲𝘀 𝗔𝗯𝗼𝘂𝘁 𝟭,𝟵𝟬𝟬 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝘁𝗼 𝗧𝗮𝗿𝗴𝗲𝘁 𝟯𝟬,𝟬𝟬𝟬+ 𝗥𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝗶𝗲𝘀

The credential theft campaign known as GhostAction accelerated in early October 2026, targeting more than 30,000 repositories. The spike resulted from the compromise of about 1,900 GitHub accounts. The campaign has been active since 2025 and according to researchers, never really stopped. The latest wave was larger than earlier ones and appears to rely in part on old, unrotated secrets.

📊 𝗧𝗵𝗲 𝗦𝗰𝗮𝗹𝗲
The campaign attempted to extract thousands of secrets from the CI environments of public repositories. It has targeted CI/CD secrets, cloud credentials, registry tokens such as npm, PyPI and DockerHub and AI provider API keys.

🛠️ 𝗛𝗼𝘄 𝗜𝘁 𝗪𝗼𝗿𝗸𝘀
Attackers appear to gain write access to repositories using stolen credentials, likely sourced from leaked tokens, infostealer logs and credential dumps. Using the hijacked maintainer account, they push a malicious workflow file disguised under deceptive names such as security-audit.yml or github_actions_security.yml.

🔄 𝗣𝗮𝘆𝗹𝗼𝗮𝗱 𝗘𝘃𝗼𝗹𝘂𝘁𝗶𝗼𝗻
• The first version added a git history secret-scanning feature to hunt for AWS key IDs, GitHub and GitLab personal access tokens, AI-related secrets and other cloud secrets.
• The second version added context retrieval around AWS key IDs to extract the corresponding secrets.
• The final version added support for retrieving that secret context during the git history scan itself.

🚀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗣𝗵𝗮𝘀𝗲𝘀
The payload was deployed in multiple phases, first against previously observed victims and then against a much larger set of new repositories. Some of the victims had already been compromised in earlier waves which suggests the threat actors are likely relying in part on secrets that were never rotated. GitHub started preventing the malicious workflow from running on October 9, so later waves using the same payload could not extract any secrets.

✅ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Rotate every secret that may have been exposed. Repeat victims suggest old, unrotated secrets are being reused.
• Find and revoke the GitHub credential that allowed the workflow injection, otherwise it can be used again.
• Tighten governance of developer accounts and tokens, since compromised credentials appear to be the entry point.

🔐 Strengthening CI/CD security starts with knowing which credentials exist, who can change workflows and how quickly exposed secrets can be rotated.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://blog.gitguardian.com/ghostaction-github-actions-supply-chain-attack-returns/

10/16/2026

🚨 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝗮 𝗱𝗿𝗼𝗻𝗲 𝗴𝗲𝘁𝘀 𝗵𝗮𝗰𝗸𝗲𝗱 𝗶𝗻 𝗺𝗶𝗱𝗮𝗶𝗿?

Drones are no longer just flying cameras. They're connected computers operating in increasingly sensitive environments. And that makes cybersecurity a serious concern.

🎙️ In the latest episode of 𝗦𝗲𝗰𝘂𝗿𝗲 𝗯𝘆 𝗗𝗲𝘀𝗶𝗴𝗻, powered by 𝗦𝗲𝗰𝗻𝗼𝗿𝗮, our host 𝗗𝗮𝗻𝗶𝗲𝗹 𝗞𝘂𝗹𝗶𝗴 sits down with 𝗠𝗶𝗰𝗵𝗮𝗲𝗹 𝗛𝗶𝗹𝗹, known as "𝗧𝗵𝗲 𝗗𝗿𝗼𝗻𝗲 𝗣𝗿𝗼𝗧𝗠️", to explore the rapidly evolving world of drone technology and cybersecurity.

From GPS spoofing and autonomous flight to data protection, supply chain vulnerabilities, and real-world cyber threats, this conversation reveals why securing the skies is becoming just as important as securing our networks.

Michael brings years of hands-on experience and a fascinating perspective on where the drone industry is heading.

🎧 𝗖𝗮𝘁𝗰𝗵 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗰𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻:
▶️ Spotify: https://open.spotify.com/episode/3jXMCDFJNqnwjAefHCU7G9?si=QeVB-LuuT724v8UQs6kOYw

𝗧𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮𝘃𝗶𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀. 𝗕𝘂𝘁 𝗶𝘀 𝗶𝘁 𝘀𝗲𝗰𝘂𝗿𝗲?

SECNORA Podcast · Episode

10/14/2026

🔍 𝗙𝗼𝗿𝗲𝗻𝘀𝗶𝗰 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 𝗼𝗳 𝗔𝗜-𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗲𝗱 𝗘𝘅𝗽𝗹𝗼𝗶𝘁𝘀

An exploit can run flawlessly without establishing who wrote it or whether AI contributed to its development.

The forensic challenge is separating how the code was developed, how it was executed and who controlled the activity.

🧩 𝗔𝗜 𝗜𝗻𝘃𝗼𝗹𝘃𝗲𝗺𝗲𝗻𝘁 ≠ 𝗔𝗰𝘁𝗼𝗿 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻
"AI-generated" means AI-assisted development, code generated by a specific model or a process directed by a particular actor. Each claim needs separate evidence, since proving one does not prove the others. Exploits may combine generated snippets, public proof-of-concept code and manual edits. Inherited bugs, unusual constants and copied typos are code-lineage clues, not proof of AI involvement. Compare against known implementations before attributing similarities to a source.

⚖️ 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝘃𝘀. 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝘃𝗶𝗱𝗲𝗻𝗰𝗲
Development evidence includes repository history, IDE or agent session records, prompt logs and provider API records. In order to link an AI response to a recovered exploit, it is necessary to obtain corroboration by means of a code comparison, examination of file revisions or use of hashes.

Evidence relating to ex*****on such as process trees, command lines, network flows and memory artifacts can show how an exploit was carried out, not how it was developed.

The git history should be examined since the dates for both author and committer can be configured, rebases and amended commits have the ability to rewrite the history and the compile timestamps can be changed or set to zero. Checks should be made by comparing the commits with the records kept by the hosting platform with the local reflogs and with other independent evidence.

🧪 𝗪𝗵𝘆 𝗖𝗼𝗱𝗲-𝗕𝗮𝘀𝗲𝗱 𝗔𝘁𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 𝗛𝗮𝘀 𝗟𝗶𝗺𝗶𝘁𝘀
Even with corroboration, code-based methods have limitations. Formatting, renaming and structural changes can weaken stylometry and code watermarks. A missing watermark doesn't prove human authorship and a detected one does not identify the operator. Evidence independence matters too. Multiple artifacts derived from one compromised log do not constitute independent confirmation.

🔗 𝗕𝘂𝗶𝗹𝗱 𝗮 𝗗𝗲𝗳𝗲𝗻𝘀𝗶𝗯𝗹𝗲 𝗙𝗶𝗻𝗱𝗶𝗻𝗴
The strongest approach tests competing hypotheses, preserves evidence, hashes acquired artifacts and maintains chain of custody. Timestamp normalization should account for clock differences and uncertainty.

Classify conclusions as Observed, Inferred or Unresolved to distinguish direct evidence from interpretation and remaining gaps. "Consistent with AI assistance" may be defensible. Attributing code to a specific model and actor requires corroborating evidence.

🎯 AI exploit attribution is a provenance investigation, not a code-styling verdict. The strength of the conclusion must match the strength of the evidence.

10/12/2026

🚨 𝗚𝗼𝗕𝗮𝗹𝗮𝗻𝗰𝗲 𝗙𝗹𝗮𝘄 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹𝗹𝘆 𝗘𝘅𝗽𝗼𝘀𝗲𝘀 .𝗼𝗻𝗶𝗼𝗻 𝗔𝗱𝗱𝗿𝗲𝘀𝘀𝗲𝘀 𝘁𝗼 𝗛𝗶𝗷𝗮𝗰𝗸 𝗮𝘀 𝗔𝘁𝘁𝗮𝗰𝗸𝗲𝗿𝘀 𝗥𝗲𝗰𝗼𝘃𝗲𝗿 𝗠𝗮𝘀𝘁𝗲𝗿 𝗦𝗶𝗴𝗻𝗶𝗻𝗴 𝗞𝗲𝘆𝘀

A signing bug in GoBalance lets attackers recover the master signing key behind an affected .onion address from public information alone and redirect it to their own site. Dread, a prominent darknet forum, had its two addresses redirected to a rival platform, Conclave, between 5 and 7 October 2026 and the second takeover is most closely linked to the flaw. Several marketplaces on the same software were also reportedly affected.

🔬 𝗥𝗼𝗼𝘁 𝗖𝗮𝘂𝘀𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗼𝗿 𝗦𝗶𝗴𝗻𝗶𝗻𝗴 𝗦𝘁𝗲𝗽
An .onion address is a public key, so whoever holds the matching private key controls the address. GoBalance is a Go rewrite of Onionbalance. A Tor private key is 64 bytes and GoBalance passed only the first 32 to the signer. The dropped half is what keeps each signature’s nonce secret. Without it, the nonce becomes publicly computable, so a single public descriptor carries enough information to recover the master secret scalar.

🎯 𝗔𝗳𝗳𝗲𝗰𝘁𝗲𝗱 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻𝘀
GoBalance ships with EndGame, a toolkit built by darknet operators to keep sites online during DoS attacks. The flaw sits in the Go rewrite only and the original Onionbalance and Tor itself are not affected. Exposure depends on how the master key was created. Sites storing it in Tor’s native format are affected while standard ed25519 keys are not. Dread’s founder says every released version is affected and other hidden services may be too and the full extent is unknown.

🧭 𝗜𝗺𝗽𝗮𝗰𝘁 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝗶𝗲𝘀
Hijacking an address lets an attacker redirect visitors to a copy of the site. It does not by itself grant access to servers, databases or stored user data. A notice on the hijacked address claimed control of Dread’s key and sensitive data and neither claim is verified. Visitors reach an attacker-run copy, so credential capture or traffic interception remains possible and Dread’s founder advised changing passwords.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• A patch alone does not close the exposure. Because descriptors are public, a vulnerable Tor-format key can be recovered by anyone, so affected operators may need a new address.
• Key handling and code flaws are separate risks. Dread's administrators first blamed the main takeover on a key upload, while the backup takeover is seen as the stronger sign of the flaw.
• Reimplementations carry their own risk. The weakness lies in the Go rewrite and not in Tor or the original Onionbalance, so code that slices or converts key material deserves close review.
• Users should confirm new addresses through signed announcements and avoid unverified mirrors.

🔗 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲: https://www.slcyber.io/research/leaking-the-keys-to-the-kingdom-how-a-single-slip-handed-over-a-darknet-empire

10/09/2026

🚨 𝗖𝗮𝘀𝗲 𝗦𝘁𝘂𝗱𝘆 - 𝗣𝗲𝗻𝘁𝗮𝗴𝗼𝗻 𝗗𝗠𝗗𝗖 𝗕𝗿𝗲𝗮𝗰𝗵: 𝗢𝗻𝗲 𝗙𝗶𝗹𝗲-𝗦𝗵𝗮𝗿𝗶𝗻𝗴 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆, 𝗔𝗿𝗼𝘂𝗻𝗱 𝟯 𝗠𝗶𝗹𝗹𝗶𝗼𝗻 𝗣𝗲𝗼𝗽𝗹𝗲 𝗔𝗳𝗳𝗲𝗰𝘁𝗲𝗱

A breach at the Defense Manpower Data Center (DMDC) has exposed the personal data of around 3 million people. Unauthorized users accessed a file-sharing server holding unencrypted personal data for roughly nine months before the vulnerability was discovered. This case is a reminder that a single exposed system holding unencrypted data can contribute to an incident of this scale.

🔍 𝗧𝗵𝗲 𝗧𝗮𝗿𝗴𝗲𝘁 𝗮𝗻𝗱 𝗦𝗰𝗼𝗽𝗲
The DMDC maintains personnel records for the Department of Defense. Reported figures put the breach at approximately 2.76 million living individuals and around 294,000 deceased individuals. The unencrypted data included Social Security numbers, names, dates of birth, contact details and in some cases military occupational specialties. The exposed fields varied by person.

⚙️ 𝗧𝗵𝗲 𝗔𝘁𝘁𝗮𝗰𝗸 𝗩𝗲𝗰𝘁𝗼𝗿
Unauthorized users accessed a DMDC file-sharing server through a security vulnerability. DMDC has not named the affected product, described the flaw or said who was behind the access. It is also unclear whether a patch was available before the issue was discovered, so the root cause remains unconfirmed.

⏳ 𝗧𝗵𝗲 𝗗𝘄𝗲𝗹𝗹 𝗧𝗶𝗺𝗲
Access began in October 2025 and went undetected until July 2026, roughly nine months. A gap of that length may point to limitations in continuous monitoring and anomaly detection, though DMDC has not shared details on how the access occurred or whether it was continuous.

🛡️ 𝗧𝗵𝗲 𝗥𝗲𝗺𝗲𝗱𝗶𝗮𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲
After discovering the vulnerability in July 2026, DMDC updated the file-sharing system to patch it and restored operations. No public claim of responsibility has been reported at the time of writing. Affected individuals are being offered 12 months of credit monitoring.

💡 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Encrypt Data at Rest: Sensitive PII stored unencrypted on a file-sharing server can significantly increase the impact of any unauthorized access. Strong encryption at rest, combined with tight access controls and data minimisation, is a baseline control for compliance and risk reduction.
• Accelerate Patch Management: File-sharing platforms can be attractive targets for initial access. Timely patching, asset inventory and regular vulnerability scanning help reduce the external attack surface.
• Strengthen Threat Hunting: Automated alerts alone may not surface every intrusion. In this case, the issue appears to have come to light through the vulnerability rather than detection of the access itself. Proactive threat hunting and well-tuned SIEM monitoring can help detect unauthorized access sooner and shorten dwell time.

10/08/2026

🔐 Cybersecurity Awareness Month

Many security incidents begin with an assumption nobody questioned.

Some cybersecurity beliefs sound right until you look a little closer. A strong password, two-factor authentication, a clean-looking email or a familiar search result can all feel like proof that things are safe. But those signals alone don’t always tell the full story.

This Cybersecurity Awareness Month, 10 common cybersecurity beliefs deserve a closer look. They range from MFA and password reuse to fake CAPTCHA pages, sponsored search ads and AI chatbots. Each slide takes one belief and busts it.

The most dangerous assumption is the one you never question.

➡️ Swipe through and see how many of these you have believed. Pause. Verify. Think before you trust.