Absolutely wild find by Argus-Systems. A remote authentication bypass hiding in OpenBSD's kernel PPP stack since it was imported from FreeBSD in July 1999.
An attacker could essentially bypass authentication via a null-auth flaw and intercept/read PPPoE traffic without credentials. It survived every single release for nearly three decades until the patch.
OpenBSD already released a patch.

I registered an expired DMARC reporting domain (gca-emailauth[.]org) for $10. It had been published as the aggregate-reporting address in Global Cyber Alliance DMARC training docs going back to a 2019 bootcamp, and at some point it lapsed.

Shortly after registration, aggregate DMARC reports for 86 domains across 20+ organizations started arriving.

56 belonged to The Toro Company (NYSE-listed), including myturf[.]com, their distributor platform, which sits at p=none. The rest - University of Wisconsin–Stevens Point (14 subdomains), the North Carolina School of Science and Mathematics, Ennis ISD (Texas), Great Prairie AEA (an Iowa education agency serving 35,000 students), two county governments, and several commercial domains.

For most of these it was a second rua address sitting behind a working commercial processor (Proofpoint, in Toro's case). Reports still arrived at the primary.

GCA's engineers later traced it to a former partner who'd held the domain and let it lapse - the dependency was never written down.

As of my last sweep, 65 of the 86 still publish the endpoint. We disclosed to everyone whose reports we were receiving; only 21 domains stopped publishing the endpoint, and almost nobody replied.

After 8 months of owning the domain, we coordinated a transfer back to GCA.

I finally found some time to organize my notes on secure boot, remote attestation, measured boot and in general embedded security.

This is not ground breaking zero-day research but I figured some of you might like a good story. Good here is obviously subjective but I felt like it came out quite readable.

This blog builds heavily on public research so as already stated at the end of article if you liked some particular section, show the respective person some love :)

P.S.: yes I know the image is AI generated please don’t give me shit for that

Evil Fonts deceive a viewer by rendering a different letter than is actually on the disk. Evil Fonts can poison HTML, DOCX, PDFs, and anywhere else you can bring your own fonts. Works great in Windows corporate networks for bypassing security tooling, initial access through JavaScript free click fix (beats mitm web security tooling), and leaving traps around the network to harvest shells.

Imagine thinking you are copying whoami but what is actually on the disk is rm -rf \~

Demos:

(Use desktop)

https://doctoreww.github.io/EvilFontTool/

For the demos, copy and paste the HTML/DOCX to a notepad to remove the evil fonts. For the AI ones imagine your security tooling inspects the benign text on disk, but shows the obviously malicious extortion to the user.

Labs:

https://github.com/DoctorEww/EvilFontTool/blob/main/labs%2FREADME.md

Lab Walkthrough:

https://github.com/DoctorEww/EvilFontTool/blob/main/labs%2Fwalkthrough.md

Some evil font uses:

Tamper homework to make it so students poison AI queries

Poison help desk documentation

Bypass email filters

Clickfix

Beat resume AI filters

Despite all the hype around Mythos, Claude Fable 5 returned pretty mid-tier results on coding tasks: 59.8% passing functional solves and just 19.0% passing security solves on a benchmark of 200 real-world tasks.

I scanned Chrome extension manifests for chrome_settings_overrides and found 23 extensions silently routing 758,000 users' searches through hidden monetization networks.

The pattern: install a free extension (satellite imagery, maps, news reader), your default search gets quietly replaced and every query goes through the operator's middleware before reaching a search network, generating affiliate revenue you never consented to.

Key findings:

• 8 distinct brokers behind these extensions. If one extension gets pulled, another goes up under a different name.
• Several extensions have zero functionality beyond the search override
• One extension affirmatively claims "We don't track your searches" while its own privacy policy says otherwise
• One uses runtime declarativeNetRequest injection so the real behavior is invisible to static analysis

The `hspart` parameter in the final search redirect URL is the clustering key. One value maps an entire broker network regardless of extension name, domain, or publisher identity.

Full report: https://malext.io/reports/SearchJack/

Noma Security published a technique they call GitLost against GitHub Agentic Workflows (the plain-English-Markdown agent feature GitHub put into public preview in February, runnable on Copilot, Claude, Gemini, or Codex). Worth reading because it is a clean demonstration of why "filter the injection" does not hold as a defense.

The setup. Workflows are read-only by default, but an org can hand one a personal access token with read access across its repos, private ones included, to give the agent cross-repo context. That grant is the whole vulnerability. Nothing else about the attack requires access: no stolen creds, no write access to anything private, no touching a server. The attacker just opens a normal-looking issue on a public repo.

The technique is indirect prompt injection, which is not new, but the interesting part is what the agent controls. Noma's Sasi Levi frames the distinction as earlier injection being about manipulating what an agent says, versus GitLost being about what an agent does with its permissions. The agent here is a credentialed actor sitting in CI/CD-adjacent infrastructure with read scope over repos the attacker cannot see. In their PoC the malicious issue was dressed as a routine request from a "VP of Sales" after a customer meeting. A normal automation assigned the issue, the agent read it, pulled a private repo's README, and pasted it into a public comment. That public comment is the exfiltration channel.

The guardrail bypass is the part netsec will care about. GitHub built defenses for exactly this class: sandboxing, read-only tokens by default, input cleaning, and a threat-detection step that scans the agent's proposed output before it posts. GitHub's own architecture docs are explicit that they design assuming the agent is already compromised (dedicated container, egress firewall, an MCP gateway container that holds the PAT so the agent process never touches it). Noma reported that prefixing the malicious instruction with a single word, "Additionally," got the model to treat it as a follow-on task rather than something to refuse, and the output scanner let it through.

This maps cleanly onto Simon Willison's "lethal trifecta": an agent that (1) can reach private data, (2) ingests untrusted external content, and (3) has a way to send data out. All three present means a leak path, and Levi is explicit that this is structural, not a patch target. In natural language there is no clean data/instruction boundary the way there is in parameterized SQL, so the mitigation is architectural (isolation, scoped credentials, staged human review) rather than pattern-matching the payload away.

Not an isolated finding either, this is a whole class:
- Anthropic's Claude Code GitHub Action: a single malicious issue pushed the agent into leaking secrets and seizing write access (Aikido).
- Orca's RoguePilot: a hidden prompt in an issue made Copilot leak a repo's privileged token.
- Invariant Labs (May 2025): a public issue drove a GitHub MCP-connected agent into reading a private repo and leaking it via PR. They called it architectural then too.
- "Comment and Control": cross-vendor study that got Claude Code, Gemini CLI, and Copilot to leak their own API keys through issue/PR text.

Mitigations that actually reduce scope (from Noma):
- Scope the integration PAT to the single repo the workflow triages, not org-wide read. This is the biggest lever. A token that sees one repo is far less dangerous than one with broad org read granted for convenience.
- Limit what a public-facing workflow can post, since the comment is the exfil channel (safe outputs).
- Restrict which authors' content the agent will act on.
- Gate outputs behind human review. The threat-detection scan is a backstop, not a boundary, as the one-word bypass shows.

At Bug Bounty Village during DEF CON 34, Inti De Ceukelaire delivered a talk on how attackers can abuse today's AI agents in ways most defenders haven't thought about yet, from tricking agents into spilling secrets to forcing them to carry out unauthorized actions on behalf of the victim.

This resulted in over $50,000+ in bounties in just a few weekends, without actually poking the target with Burp Suite or any automated scanners.

Author here. I audited NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Airflow and disclosed 14 findings. Every platform inherited the same assumption anyone who can touch a workflow is trusted to run code on the host, which is fine for a dev tool on your laptop but not fine for a multi-tenant HTTP service with an unauthenticated webhook. The chain I'd point people to first is the Flowise one (section 2.2): an unauthenticated request → prompt injection → LLM emits Python → a 38-pattern regex blocklist passes it because the dangerous library was pre-imported before the model was asked anything → RCE.

Two vendors closed their reports as working-as-intended, and I tried to represent their position fairly.

This research was also presented at DEFCON 34 but now available publicly.

Happy to answer questions.

Full whitepaper is available here: https://www.endorlabs.com/learn/how-ai-orchestration-platforms-ship-rce-by-design

A technical audit evaluating the security defaults of 15 official Helm charts used for AI serving, vector databases, and Model Context Protocol (MCP) agents (including KubeRay, vLLM, LiteLLM, Qdrant, Weaviate, and Flux159 MCP).

Key findings from static manifest analysis and live single-pod lateral movement probes on a test cluster:

• Plaintext Secret Handling: LiteLLM database migration Job embeds raw database passwords in container environment variables (F-13).
• Unauthenticated Remote Code Execution: KubeRay defaults accept unauthenticated job submissions via HTTP, running commands inside a container with passwordless sudo access.
• Over-privileged Agent Access: Flux159 Kubernetes MCP server mounts a ClusterRole with cluster-wide Secret read and pod exec permissions, exposed without an authentication token over HTTP.
• Static Scanners vs CRDs: Standard static analysis tools (Checkov, Trivy, Kubescape) failed to inspect pods nested inside Custom Resource Definitions like Ray clusters.

The paper documents reproducible test commands, network capture logs, and remediation Helm snippets. Scrubbed raw probe logs and results tables are available on GitHub: https://github.com/Sorami-Consulting-AU/ai-kubernetes-helm-chart-security

TL;DR. The FortiPAM Chrome extension (1M+ users), used for Privileged Access Management, allowed any site to set the browser's proxy for the session, alongside allowing any site to create a new tab and send screen recordings of it to an attacker's server. That makes for trivial phishing attacks which only require the user to view something sensitive in the attacker-opened tab. CVSS 9.1 | CVE-2026-84388.

- Google's own nameserver vouched for Russian IPs as Googlebot.

- One PTR addresses AI agents directly, and it passes forward confirmation.

- The exfil payload dodges filters for spaces, parentheses and quotes, and phones home to an IP written as one decimal number.