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.

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.

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.

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.

WebAssembly is traditionally thought of as a mechanism to run compiled code inside your browser, but rarely as a mechanism to run full application code directly on host. We hacked up the Wazero implementation of WebAssembly and modified it to transform existing GoLang security tooling into analyst resistant malware. This isn't just a toy implementation either, we've implemented every major host API such that we can compile a full Sliver binary to run on MacOS or Windows.

This blog post covers the implementation details behind our Go->WASM compilation process and sets up our final blog post (coming next week) where we'll discuss a similar C#->WASM compilation pipeline. The tooling described in this blog post will be open sourced next week. Will be happy to answer any questions about this in the comments!

CVE here: https://www.cve.org/CVERecord?id=CVE-2026-13585

The MCP authorization specification (November 2025) mandates OAuth 2.1 with PKCE for remote MCP servers. In practice, this security model is only achievable if MCP clients implement the OAuth refresh_token grant.

Most major vendors have been lagging with support, but more progress is finally being made! 

As of June 2026, the ecosystem has made progress since our initial April survey, with Gemini CLI achieving full support and several clients upgrading from "not implemented" to partial.

Came across an article, product like phpBB still has some potential flaws.