DEV Community: Sarah Reid

Chrome Removed the eMudhra Root Today: What to Replace Before the Oct 28 AWS Deadline

Sarah Reid — Tue, 27 Oct 2026 14:16:51 +0000

By Sarah Reid, Securetron. I am Sarah Reid, with Securetron, and this is a practical briefing for teams that still have certificates chaining to the affected eMudhra roots.

Today, October 27, 2026, is the day Chrome started removing the emSign ECC Root CA-G3 root. Tomorrow, October 28, 2026, is the deadline in AWS bulletin 2026-150-AWS for replacing certain Application Load Balancer (ALB) OIDC/JWT certificates. If you have not inventoried your chains yet, those two dates leave no room to treat this as a routine renewal cycle.

What changed on October 27

Chrome started removing the emSign ECC Root CA-G3 root on October 27, 2026. In practical terms, a root removal means Chrome will no longer trust certificates that chain to that root. That is the point of a root store decision: it is not a warning about a single certificate, it is a change to the trust anchor underneath a whole set of certificates.

The scale of the remaining exposure was already visible before removal day. About 30,800 unexpired precertificates were counted on October 21, with 99.9 percent issued via InCommon intermediates. Those figures are reported in coverage of the Chrome removal, drawing on Certificate Transparency data. See: Chrome Removes eMudhra Root — Convika and Tanium on finding and fixing eMudhra exposure.

Do not read the precertificate count as a count of live, in-use leaf certificates in your environment. Precertificates are the Certificate Transparency records created before issuance. The count shows how widely the affected chains were used, and why a manual, one-certificate-at-a-time check is not a sufficient response. Your job is to find the chains you actually rely on, not to debate the global total.

Oracle and Java: a second emergency alert

Browsers are not the only trust store that matters. Oracle issued a second emergency Java alert on October 24, CVE-2026-114820, with a CVSS score of 9.1, removing affected roots. Source: Oracle Security Alert CVE-2026-114820.

That matters because Java applications, services, and build and runtime environments often carry their own trust stores, separate from the browser. A certificate that is replaced for Chrome may still be trusted — or still be relied on — in a Java trust store until that store is updated, and a Java client that has removed the root will reject a chain that other parts of your stack still accept. Check both. The browser deadline and the Java update are part of the same trust change, not two unrelated incidents.

The October 28 AWS deadline

AWS bulletin 2026-150-AWS requires ALB OIDC/JWT certificates chaining to the three affected roots to be replaced by October 28, 2026. Source: AWS Security Bulletin 2026-150-AWS.

Read that requirement narrowly and act on it literally:

It is about ALB OIDC/JWT certificates, not every certificate in your AWS account.
It is about certificates chaining to the three affected roots named in the bulletin.
The replacement deadline is October 28, 2026.

If you run ALBs with OIDC or JWT authentication, check the certificate chain for each listener and identity configuration now. A certificate that looks valid in the console can still chain to an affected root. Replace it with a certificate chaining to a trusted root, test the OIDC/JWT flow end to end, and confirm the old certificate is no longer in use before you assume the deadline is met.

What to do today: a short, checkable list

1. Inventory chains, not just certificates. List every TLS, OIDC, and JWT certificate in use, then inspect the full chain for each one, including intermediates. The InCommon intermediate figure in the October 21 count is a reminder to look past the leaf: an intermediate can tie an otherwise ordinary-looking certificate to an affected root.

2. Search Certificate Transparency and your own records. Use CT logs to find precertificates and certificates for your domains, and reconcile them with your internal inventory. If CT shows a chain you do not recognize, treat it as a finding to investigate, not as background noise.

3. Prioritize ALB OIDC/JWT first. Those are the certificates with an explicit October 28 AWS deadline. Replace, redeploy, and test authentication before moving on to lower-priority renewals.

4. Check Java trust stores separately. Apply the Oracle alert, update Java trust stores, and test Java clients and services that validate these chains. Do not assume a browser fix covers a Java runtime.

5. Reissue from a trusted CA and verify the new chain. After replacement, confirm the new chain in a browser, in your ALB configuration, and in any Java or non-browser client that validates it. Keep the old certificate out of rotation; a replaced certificate that is still configured somewhere is not replaced.

6. Monitor after replacement. Watch for trust errors, failed OIDC/JWT validations, and client complaints in the days after October 27 and 28. Root removals surface in client errors first, and the error is often reported as an authentication failure rather than a certificate problem.

The Securetron PKI Trust Manager angle

This is the kind of problem PKI tooling exists to make visible: which certificates you have, which roots and intermediates they chain to, when they expire, and where each one is actually deployed. Without that inventory, teams discover affected chains one outage at a time.

Disclosure: I am Sarah Reid, with Securetron. Securetron PKI Trust Manager is Securetron's offering in this area, intended to help teams inventory certificates and track their trust chains. The Community Edition is free for up to 500 certificates, per the product information in the source material for this article.

Whether you use PKI Trust Manager or another inventory, the questions to answer before October 28 are the same: can you list every certificate chaining to an affected root, can you prove each ALB OIDC/JWT certificate has been replaced, and can you show the new chain validates in Chrome, in AWS, and in Java? If you cannot answer all three from one inventory, the inventory is incomplete.

Bottom line

Chrome started removing the emSign ECC Root CA-G3 root on October 27, 2026. Oracle had already issued its second emergency Java alert on October 24 for CVE-2026-114820, CVSS 9.1, removing affected roots. AWS requires ALB OIDC/JWT certificates chaining to the three affected roots to be replaced by October 28, 2026. About 30,800 unexpired precertificates were counted on October 21, 99.9 percent via InCommon intermediates — a measure of how widely these chains were used, and why checking only the certificates you remember is not enough.

Replace the affected chains, verify the new ones in every trust store that matters, and do it before the October 28 deadline, not after the first failed login tells you that you missed one.

Sarah Reid is with Securetron.

Sources: Convika, https://convika.com/blog/chrome-removes-emudhra-root-2026-10-27/ ; Tanium, https://www.tanium.com/blog/emudhra-ca-compromise-find-and-fix-your-exposure-with-tanium ; Oracle, https://www.oracle.com/security-alerts/alert-cve-2026-114820.html ; AWS, https://aws.amazon.com/security/security-bulletins/2026-150-aws/

Your AGENTS.md Is an Attack Surface: How a Trusted File Hijacked Codex and Claude Code

Sarah Reid — Tue, 27 Oct 2026 14:14:30 +0000

By Sarah Reid, Securetron. I work at Securetron, and this article explains research into a prompt-injection technique affecting AI coding agents — and the controls that help stop it.

AGENTS.md was meant to make coding agents more useful. Put project instructions in one file, and the agent follows them: how to build, how to test, where the code lives, and which commands are safe. That convenience is exactly what makes the file interesting to an attacker. If an agent treats AGENTS.md as trusted instructions, then whoever controls that file can steer the agent.

That is the core finding in research reported by Forever Security. In its testing against Codex, the reported success rate was over 90%. That number deserves careful reading: it describes success in the researchers' test setup, not a measured rate of compromise in the wild. It is still a warning worth taking seriously, because the failure mode is not a bug in one model. It is a trust problem in how agents consume context.

How the hijack works

A coding agent does not usually ask whether AGENTS.md should be trusted. It reads the file as part of its working context, then acts on it. A malicious or tampered AGENTS.md can therefore do what a normal instruction file does, only with a different goal:

The agent opens a repository and loads AGENTS.md automatically.
The file contains instructions that look like ordinary project guidance — run a setup step, use a particular tool, or follow a workflow.
The agent follows the instructions, including tool calls, shell commands, or requests that a careful human reviewer would question.
If the agent has access to credentials, source code, or network egress, the consequences go beyond a bad code change.

The research describes this using function coloring and MALFEX techniques. In plain terms, the attack is about making malicious instructions blend in with legitimate agent behavior: the file steers the agent toward attacker-chosen functions and actions while looking like a normal part of the project. Do not treat that as a reason to reproduce payloads. The defensive lesson is simpler — context files are code, and they need the same review as code.

The Claude Code token-replay risk: ANTHROPIC_BASE_URL

A second, related risk concerns where the agent sends its API traffic. Claude Code uses ANTHROPIC_BASE_URL to determine the API endpoint it talks to. If that value is changed — for example, by an instruction, a configuration change, or an environment change the agent is persuaded to accept — API requests, including the credentials or tokens that authenticate them, can be directed to an endpoint the attacker controls.

That is the token-replay concern in practical terms: a token sent to the wrong endpoint can be captured and replayed. The fix is not to memorize one variable name. It is to treat endpoint configuration as a security boundary. Teams should:

Verify ANTHROPIC_BASE_URL (and equivalent endpoint settings for other tools) in a trusted configuration, not in instructions supplied by a repository you have just cloned.
Refuse agent-proposed changes to API endpoints, proxy settings, and credential handling without human review.
Use short-lived, least-privilege credentials for agent work, and be able to revoke them quickly.
Monitor for unexpected API endpoints and unusual token use, rather than discovering a redirect after the fact.

If an agent asks to change where it sends traffic, that is a stop-and-review moment, not a routine setup step.

An important caveat: the delivery route was not confirmed

Be precise about what this research does and does not show. The technique was demonstrated, and the reported Codex success rate was over 90% in testing. The delivery route — how a malicious AGENTS.md would reliably reach a victim's agent in a real attack — was not confirmed.

That caveat matters. It means this should not be described as a confirmed in-the-wild campaign, and teams should not assume every cloned repository is already compromised. It also does not make the issue theoretical. A demonstrated way to steer a trusted agent, combined with an unconfirmed but plausible delivery path through shared repositories, forks, and copied project templates, is enough to justify controls now. The right response is proportionate defense, not panic.

Practical defenses that actually help

Start by changing how AGENTS.md is treated in your workflow:

1. Review AGENTS.md like code. Require pull-request review for AGENTS.md and other agent instruction files. Use CODEOWNERS or an equivalent approval rule so a single contributor cannot silently change what agents are told to do. Check diffs, not just the final file.

2. Do not run an agent in an untrusted checkout with full privileges. Before running a coding agent on a repository you did not author, inspect AGENTS.md, configuration files, and setup scripts. If you do not need the file, remove or quarantine it for that run, or run in a disposable environment.

3. Require human approval for consequential actions. Shell execution, network requests, package installation, credential access, and changes outside the working tree should require explicit approval. An agent that can act without friction is an agent that can be steered without friction.

4. Apply least privilege and network controls. Give agents the minimum repository, filesystem, and secret access they need. Block or allowlist network egress where possible, and do not let an agent session hold production credentials or long-lived tokens.

5. Separate build, test, and secret-handling contexts. Do not let the same agent session that reads untrusted instructions also read secrets from the environment. Where possible, run untrusted work without secrets mounted, and inject credentials only in a controlled, reviewed step.

6. Log and audit agent actions. Keep a record of tool calls, commands, and endpoint changes. If an agent follows a suspicious instruction, you need to know what it did, what it accessed, and which credentials were in scope at the time.

7. Pin and verify your tool configuration. Endpoint URLs, model settings, and plugin or MCP server configurations should come from trusted, version-controlled configuration — reviewed separately from repository content. Alert on changes.

These controls do not require trusting a single vendor. They follow from one principle: untrusted text should not become trusted action without a human or a policy check in between.

Disclosure: Securetron AI-FW

Disclosure: I am Sarah Reid, with Securetron. The section below describes a Securetron product. It is included so readers can evaluate a vendor control in context, not as an independent endorsement.

Securetron AI-FW is Securetron's AI firewall offering, intended to help teams inspect and control traffic and actions from AI agents. The Community Edition is proprietary software that is free to use, for up to 10 billion tokens per month. It is not open source, and this article does not claim otherwise.

Whether you use AI-FW or another control, the evaluation questions are the same: does it see agent tool calls and API traffic, can it block or require approval for high-risk actions, does it log what happened, and can it enforce endpoint and credential policies without depending on the instructions in the repository itself? A control that only reads the same AGENTS.md file the agent reads will not solve the trust problem described here.

Bottom line

AGENTS.md is not just documentation. For a coding agent, it is instructions, and instructions are an attack surface. The Forever Security research — over 90% reported success against Codex in testing, function-coloring and MALFEX techniques, and the ANTHROPIC_BASE_URL token-replay risk for Claude Code — shows how far that trust can be stretched. The unconfirmed delivery route is a reason to be accurate, not a reason to wait.

Review the file. Limit the agent. Approve the consequential action. Verify the endpoint. If you do those four things consistently, a hijacked instruction file becomes a suspicious diff to reject, not a silent takeover.

Sarah Reid is with Securetron.