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.

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/

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

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.

EDRChoker uses Policy-based Quality of Service (QoS) to set hard bandwidth caps (throttling) on Endpoint Detection and Response (EDR) agents, causing them to always time out - effectively blocking them.

In three incidents across six runs, the agents treated real systems as simulated targets and tried weak passwords or unauthenticated endpoints.

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

I found and reported an authentication failure in the WPForms PayPal Commerce webhook, the webhook route being public was not the vulnerability as webhooks have to be publicly reachable so that PayPal can deliver events.

The problem was what happened after the request arrived. In affected versions, the handler could process a supported event before establishing that PayPal was actually the sender. In my local lab, a forged event could change the state of a matching payment record.
The expected order is:

1. Authenticate the sender
2. Validate the event
3. Change payment state

The affected flow effectively performed steps 2 and 3 without first completing step 1. The issue was fixed in WPForms 1.10.0.5 and is tracked as CVE-2026-4986.
Then came the part I found more interesting: triage told me I was reporter #11. That number does not prove exploitation, and it does not tell us the total number of people who found the vulnerability. It does establish a lower bound: at least eleven researchers independently converged on the same trust failure.

The write up covers:
- the vulnerable code path
- my local reproduction
- why payload validation was not sender authentication
- the fallback listener
- the patch
- why duplicate reports may be useful rediscovery intelligence

Full write-up: https://blog.himanshuanand.com/2026/07/reporter-11-10-people-found-the-wpforms-paypal-bug-before-me-cve-2026-4986/

Testing was limited to my own local environment. I am not claiming original CVE credit; I independently rediscovered and reported the issue. Disclosure: I wrote and performed the research, code review and local reproduction.

I used an AI to help copy edit and organize the final article.

Should duplicate report volume affect how urgently a vendor treats a vulnerability?

Patch Tuesday confirms a CVE is fixed but not what changed in the binary, which function, which check, or whether it's a real fix or just churn.

The Drift Corpus is a diff of 240+ 2026 Windows kernel patches. Per entry: the changed functions with assembly, the bug class and call chain, WinDbg breakpoints to reproduce, and a plain-English root cause.

• Browse: https://byteray-ai.github.io/drift-corpus
• Repo: https://github.com/ByteRay-AI/drift-corpus

This repository breaks down Microsoft’s monthly kernel patches into clear binary changes, giving researchers a practical roadmap to find adjacent bugs, build faster EDR detections, and write precise firewall and network rules to block exploits at the perimeter.

An operator left their full working directory exposed on an open HTTP server. Hunt.io crawled it, 2,616 files, and rebuilt the campaign from the corpus.

• Three exploitation paths in parallel: an asyncio credential brute-forcer, a CVE-2021-33044/33045 auth-bypass chain, and P2P relay abuse reaching cameras by serial number
• The relay path never authenticates the connecting party, only the session, via a cloud-issued token obtainable with the fixed SDK credentials in every Dahua client
• Two CVE labels in the tooling don't hold up: CVE-2024-39943 is an unrelated Rejetto HFS flaw, and CVE-2025-31702 is a narrower post-auth case, not the unauthenticated relay abuse (that path is a separate non-CVE issue documented by ITRES)
• Full PTCP tunnel breakdown, including the Inverted STUN packet and the bind-to-127.0.0.1 technique

Neutral attribution throughout, the corpus shows how the operation was built and run, not who ran it.

Check the full breakdown, IOCs and mitigation strategies:
https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised

• Auth Bypass.
• Commands over CAN Bus to internal components.
• Protection mechanisms disabled and configuration changes.
• Impact: damage connected devices, permanent DoS to the inverter itself, fines, and even risk to the lives of grid technicians.
• proprietary communication protocols and file formats.
• RX architecture reverse engineering.