The advisory, published under CVE-2026-109618, lists all releases of PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2, plus all Panorama versions, as vulnerable, with the fix date for each branch marked “TBD.” No special configuration is required for a device to be exposed. Palo Alto said it is not aware of malicious exploitation against its products.

PHP2Shell is the name given to CVE-2026-109618 and CVE-2026-109619, two memory-handling bugs in the PHP engine that the PHP project fixed on October 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP rates both 9.2 on CVSS v4.0. Researchers at Calif, Wiz and OpenAI found them in August, and details leaked online a day before the planned disclosure.

PAN-OS bundles PHP to run its management web interface, and Palo Alto says the flaws are reachable only through that interface, meaning the HTTPS web UI and the XML API. An ordinary dataplane interface becomes exposed when an interface management profile is attached to it.

The GlobalProtect portal, gateway, and Captive Portal are not affected. Cloud NGFW, Prisma Access, the GlobalProtect app, Prisma Access Agent, Prisma Cloud, and the Cortex XDR agent, XSIAM, XSOAR, and Xpanse are listed as unaffected.

How does PHP2Shell work?

CVE-2026-109618 is triggered when PHP runs out of memory while still building internal structures for an incoming request. PHP marks part of that state as ready before every allocation has finished; if an allocation fails and nothing rolls back the half-built state, the cleanup code later treats uninitialized memory as valid. Red Hat says an unauthenticated attacker can exploit this to execute code against mod_php in its default configuration.

The SANS Internet Storm Center described how an attacker exhausts memory in the first place. A multipart request sent without a Content-Length header can slip past the post_max_size limit, the number of headers is not capped, and the max_file_uploads limit ignores empty files, whose bookkeeping structures still consume memory.

CVE-2026-109619 leaves worker-global pointers pointing to memory that a previous request has already freed, so the next request served by the same PHP worker reads or branches on that stale data. Sansec traced the vulnerable code back to PHP 5.4.0, released in 2012.

Why does Palo Alto score it lower than PHP?

Palo Alto rates the issue in its own products 8.7 under CVSS-B, but the vector behind that score records a high impact on availability and no impact on confidentiality or integrity. Read literally, Palo Alto is scoring the PAN-OS risk as a firewall outage rather than a takeover. The score falls to 7.1 when only a jump box can reach the management interface.

The same advisory lists PHP’s own 9.2 score, which assumes full loss of confidentiality, integrity and availability, and does not explain why the firewall impact was assessed differently. Fortinet’s PHP2Shell advisory rates CVE-2026-109618 even higher, at 9.8 under CVSS v3.

Attackers have been probing PHP servers since before the patches landed. Amazon logged attempts on its honeypots on October 17, four days before disclosure, and Cloudflare CEO Matthew Prince said the company saw thousands of attempts in the 10 hours before the announcement. watchTowr said most exploit scripts being sprayed either fail, only test response timing, or crash the target.

“Whilst nobody has been successful to date, we don’t expect that will last long,” watchTowr head of threat intelligence Jake Knott said. CISA had not observed exploitation, and neither CVE was in its Known Exploited Vulnerabilities catalog as of October 22.

The PAN-OS management interface has been a target before. In February 2025, attackers exploited CVE-2025-0108, an authentication bypass in that interface that let them invoke PHP scripts, a day after Palo Alto released the fix.

What should PAN-OS admins do before the patch?

Palo Alto’s primary advice is to restrict the management interface to trusted internal IP addresses, as outlined in its best-practice guide, and to check every dataplane interface for an attached management profile.

Threat Prevention subscribers can enable Threat IDs 543004, 97622, 97623, 97624 and 97625, available from Applications and Threats content version 9162. The signatures only see management traffic that passes through the dataplane, so admins must route management access through a DP interface, replace the certificate used for inbound management, decrypt that traffic and apply threat prevention to it. Installing the signatures alone does not protect the out-of-band MGT port.

Customers on Advanced Threat Prevention Plus with Frontier Virtual Patching, running PAN-OS 12.2.4 or later, received signature 543004 at 10:21 p.m. PT on October 20, before PHP published its fixes.

Palo Alto is not the only appliance vendor still working on PHP2Shell. Fortinet has cleared 12 products, including FortiOS, and is reviewing 12 more, while Cisco is investigating 31 products and cloud services. The Dutch NCSC keeps a running list of vendor statuses.

Across the wider internet, Palo Alto’s Unit 42 said Cortex Xpanse had identified more than 22.6 million exposed instances potentially vulnerable to the two flaws.

The fixes land in FortiOS 8.0.2, 7.6.8, 7.4.13 and 7.2.14, and in FortiManager and FortiAnalyzer 8.0.2, 7.6.8, 7.4.12 and 7.2.13. No CVE identifiers or CVSS scores have been published. According to the announcement by Fortinet CISO Carl Windsor, the advisories will appear on the FortiGuard PSIRT portal on November 10, Fortinet’s next Patch Tuesday.

Every FortiOS build from 8.0.0 to 8.0.1, 7.6.0 to 7.6.7, 7.4.0 to 7.4.12 and 7.2.0 to 7.2.13 is affected. FortiManager and FortiAnalyzer are affected across the same 8.0 and 7.6 ranges, and up to 7.4.11 and 7.2.12 on the older branches.

FortiMail and FortiAuthenticator updates went out a day earlier. FortiMail is fixed in 8.0.2, 7.6.7 and 7.4.9, with 7.2 customers told to move to the 7.4 branch, and FortiAuthenticator is fixed in 8.0.4 and 6.6.11. Those FortiMail builds are the same ones Fortinet identified on October 1 as the fix for CVE-2026-104286, a CVSS 9.8 FortiMail flaw that had already been exploited in the wild and added to CISA’s Known Exploited Vulnerabilities (KEV) catalog that day.

FortiSASE is updated automatically. FortiManager Cloud may require a manual update, and public cloud images are pushed through each cloud provider’s release process.

Why is Fortinet holding back the vulnerability details?

Windsor’s argument rests on patch diffing, in which an attacker compares a fixed build with the vulnerable one to pinpoint the changed code, and on how much AI speeds that up. Fortinet says AI tools can now help attackers reverse-engineer a patch and build a working exploit in hours or days instead of weeks, and chain several lower-severity bugs into a single serious exploit. A detailed advisory released alongside the patch would also hand attackers the map.

“The window between disclosure and exploitation continues to shrink,” Windsor said.

That warning comes from Fortinet’s own testing. In a June update, Windsor said the company was working with Anthropic’s Glasswing (Mythos) and OpenAI’s Daybreak (GPT 5.5 Cyber) programmes. Given only the firmware, as an outside attacker would be, the models found few new exploitable bugs, but they proved highly capable of comparing firmware versions and writing proof-of-concept exploits for vulnerabilities that Fortinet had already fixed.

The source code produced very different results. Across more than 100 tests on 30 product families, Fortinet classed 40% of findings as genuine vulnerabilities, 30% as security best-practice improvements and 30% as false positives, with every finding reviewed by a human analyst. Windsor put the average token cost at about $540 per confirmed vulnerability.

This week’s announcement thanks Anthropic, OpenAI, Google and SpaceX for their collaboration. In a post on X, Fortinet said the programme is also shaping a broader quarterly security release cadence. F5 made a similar shift in July, moving to monthly hardened releases after its own frontier AI testing.

Will attackers wait until November 10?

Not everyone accepts the three-week gap. Yordan Ganchev, principal threat intelligence specialist at watchTowr, told Cybernews he expects the flaws to be reverse-engineered and exploited quickly, and argued that announcing major vulnerabilities in advance mainly primes attackers’ LLM patch-diffing tools. He pointed out that the affected products are repeat entries in CISA’s KEV catalog.

Belgium’s Centre for Cybersecurity issued a patch-immediately warning on Thursday, noting that Fortinet’s announcement contains no CVE identifiers, vulnerability classes or exploitation conditions. No exploitation of the new flaws had been reported as of Friday.

Fortinet edge devices have had a hard year. In June, the FortiBleed credential-harvesting campaign exposed logins for tens of thousands of internet-facing FortiGate firewalls, and the FortiMail zero-day followed this month. The release also lands in one of the busiest patch weeks of the year.

Defenders are already working through PHP2Shell, the critical PHP remote code execution flaws whose details leaked before the fix, and which one researcher now claims to have bypassed on PHP 8.5.12. Node2Shell, a Node.js Brotli decoder bug, has a working RCE proof of concept, and eMudhra is quitting the global TLS business after eight of its intermediate CA keys proved trivially crackable. On Thursday, Trend Micro’s ZDI also posted two unpatched CVSS 9.0 Linux KSMBD flaws to a public kernel mailing list.

What do the FortiOS release notes reveal?

The FortiOS 7.4.13 release notes, dated October 22 and covering build 2933, itemise none of the AI-found flaws. The only CVE they list is CVE-2025-54821, along with a resolved bug (1309910) described as a vulnerability that is triggered when the FortiGate connects to a malicious SSH server and sends crafted packets. Fortinet’s own known-issues entry refers to the new builds as the “Frontier AI vul fix” releases.

Two known issues are worth checking before scheduling the upgrade. Bug 1353958 causes browsers to return ERR_EMPTY_RESPONSE for HTTPS sites on non-standard ports such as 8443 when deep inspection is enabled, after upgrading to any of 7.2.14, 7.4.13, 7.6.8 or 8.0.2. Bug 1349258 causes an uninterruptible upgrade from 7.2.13 to 7.4.13 to fail on FortiGate 7000F chassis.

Fortinet wants internet-facing systems upgraded in the October 22–23 maintenance windows, with configurations backed up first and logs watched for unusual administrator logins or unapproved configuration changes before and after patching. Its release notes say FortiAnalyzer and FortiManager should be upgraded before the FortiGates they manage.

Where an upgrade has to wait, Fortinet advises restricting HTTPS and SSH administration to trusted IP addresses or disabling it on external interfaces, keeping FortiManager administration off the internet, enforcing MFA for every administrator and moving management out of band. The company says these steps reduce exposure but do not replace the update.

The reports normally go to the kernel’s private security list, so maintainers can prepare a patch before details become public. This batch was copied to public lists as well, and none included a patch. Stable-kernel maintainer Greg Kroah-Hartman replied to several reports within minutes of each other.

What the two KSMBD flaws do

ZDI-CAN-33774 is a race condition in how KSMBD picks which protocol handler processes each incoming request. KSMBD chooses the handler when a request is queued, but the worker thread reads that choice only when it picks up the job. An attacker sends a burst of short SMB1 packets followed by an SMB2 packet in the same TCP write.

That switches the connection to SMB2 handling while SMB1 buffers are still waiting, so the SMB2 code reads past the end of the smaller SMB1 buffer. Linux news site freenode reported that the leaked kernel heap bytes come back to the attacker inside an error reply.

ZDI also describes a related out-of-bounds write in KSMBD’s parsing of security descriptors, the access-control data a client sends when changing file permissions. That write path needs shared access. Freenode put the requirements as winning the race plus a share reachable as a guest, and said the bug was demonstrated against kernel 7.3-rc3. The high attack-complexity rating in ZDI’s 9.0 score reflects the need to win that race.

ZDI-CAN-33549 is an integer underflow in KSMBD’s SMB Direct path. An integer underflow is a subtraction that wraps a size value around to a huge number. SMB Direct carries SMB traffic over RDMA (remote direct memory access), a networking technology mostly found in data centres. A client can send RDMA buffer descriptors in which the first entry is longer than the declared payload. The server’s size counter then wraps, and a later memory copy overruns its buffer. Exploiting it requires an RDMA-capable interface (hardware or the rxe software driver), a writable share and a client that negotiates SMB Direct. SMB Direct support is a separate kernel build option that is off by default.

Phoronix reported that a fix for ZDI-CAN-33549 already sits in a Git branch aimed at Linux 7.5 and will likely be fast-tracked. The Hacker News found no named fix for either KSMBD bug in mainline or linux-next. The kernel project assigns CVE numbers only after a fix lands in a stable tree. Until then, vulnerability scanners that match on CVE IDs will not flag these bugs.

The other four reports carry less risk for internet-facing servers:

• ZDI-CAN-33367 is a local privilege escalation (CVSS 7.8) in the networking code’s skb_zerocopy function. Kernel developers had already received a report of the same bug from someone else the previous week, and a patch is expected.
• ZDI-CAN-34068 is an out-of-bounds write (CVSS 8.8) in vmwgfx, the graphics driver used by VMware virtual machines.
• ZDI-CAN-34076 is an information disclosure (CVSS 8.6) in the NVMe-over-fabrics target driver.
• ZDI-CAN-32005 is a stack buffer overflow in ConnMan, a network-management daemon that runs outside the kernel.

An accident, or the new kernel rules at work?

Phoronix described the postings as an apparent mistake. The reports themselves suggest otherwise: they credit TrendAI, Trend Micro’s AI vulnerability scanner, as the finder. The kernel’s security-bugs documentation, rewritten by Willy Tarreau and merged for Linux 7.1 in May 2026, says bugs found with AI tools should be treated as already public and sent to the relevant maintainers instead of the private list.

That rule followed Linus Torvald’s 17 May complaint that duplicate AI-generated reports had made the private security list “almost entirely unmanageable.” His argument was that when one AI tool finds a bug, others running similar tools find it too, so secrecy buys little. The same guidance asks reporters to send patches or clear impact analysis, not raw findings. ZDI’s reports included neither patches nor fixes.

The ZDI-CAN-33367 duplicate shows the problem Torvalds described: another researcher had found the same bug a week earlier. The policy meant to cut duplicate private reports has also put two pre-patch, 9.0-rated server bugs in public view with no fix attached. Trend Micro had not publicly explained its routing as of 23 October 2026.

Is your Linux server affected?

Only systems actually running KSMBD are exposed to the two remote flaws. KSMBD is not Samba. It is a separate, Samba-compatible server written from scratch, originally by Samsung, and Samba’s co-creator, Jeremy Allison, has said the two share no code. Ordinary Samba installations are unaffected.

KSMBD is off by default in the upstream kernel configuration. It also needs the separate ksmbd-tools userspace daemon to serve files. Red Hat Enterprise Linux does not include it. It turns up most often on home NAS boxes, single-board computers and appliances, where it is chosen for low overhead. Kernels in the Armbian project for ARM boards, for example, enable it for many devices.

To check a machine, run systemctl status ksmbd or lsmod | grep ksmbd. If KSMBD is loaded but not needed, stop the service, unload it with modprobe -r ksmbd and blacklist the module so it does not load again. Where KSMBD has to stay:

• Keep port 445 off the public internet.
• Remove guest-accessible shares.
• Leave SMB Direct disabled unless the network depends on RDMA.
• Watch your distribution’s security tracker for the backported fix.

KSMBD has been a recurring ZDI target. ZDI-22-1690 in December 2022 was an unauthenticated remote code execution flaw in the same server, and ZDI-26-573 in August 2026 was a pre-authentication memory leak rated 9.3. This batch landed the same week researcher Hyunwoo Kim disclosed the Infinity Core set of six Linux kernel privilege-escalation bugs.

No exploitation of the new KSMBD flaws has been reported. Still unknown: when the SMB Direct fix reaches mainline, when a fix for ZDI-CAN-33774 appears, and whether ZDI will route future AI-found kernel bugs the same way.

Morgan Stanley, Bank of America, JPMorgan Chase and Wells Fargo are among the lenders racing to contain the problem, according to the report, which cites unnamed people familiar with the matter.

In most cases, the agents are not breaking in. They sign in with the customer’s own username and password, handed over so an AI assistant can check balances, pay bills or move money on the customer’s behalf. That still breaches the terms at most banks, which require account holders to log in themselves.

The more worrying cases, per Axios, involve agents that contacted bank call centres or appeared to act on their own initiative, and one bank executive told the outlet that banks often cannot tell an agent a customer deliberately sent from one that has gone rogue.

Bank executives described the situation to Axios as “horrifying,” with one official citing grave concern about agents taking steps that could affect customers’ finances. Reuters, which carried the report, said it could not immediately verify it. The report does not say how many accounts were involved, which AI products the agents belonged to, or whether any customers have lost money.

Which banks are blocking AI agents

Morgan Stanley has begun blocking third-party agents from its platforms, Axios reported, although a Morgan Stanley spokesperson told the outlet the bank had not seen rogue AI agents accessing its systems. JPMorgan, Bank of America and Citigroup are restricting agents rather than banning them outright. Wells Fargo, also named in the report, has not publicly described specific restrictions.

JPMorgan Chase drew the clearest line first. On the bank’s third-quarter earnings call on 13 October, CEO Jamie Dimon said the bank would not let just any outside agent inside its systems. “You don’t want rogue agents, and it could be thousands of them,” Dimon said. A JPMorgan spokeswoman told CNBC the bank does not permit third parties to log in with customers’ banking credentials, though agents can still see read-only data, such as balances, through a connector like Plaid. She gave no timeline for letting agents act inside accounts directly.

Citigroup and Bank of America followed on 16 October. Citi told Retail Banker International that it does not allow third-party AI agents or assistants to log in to customer accounts or transact on its digital banking platforms, while still letting customers grant limited read-only access through certain open-banking providers. Bank of America is limiting agents’ access to consumer deposits, according to a person familiar with the matter, and the Financial Times reported that regulators have privately backed the banks’ decisions.

CEO Rick Wurster told Bloomberg Television on 16 October that Schwab is stopping unauthorized agents, including Meta’s Muse, from moving client money, and that his weekly report shows the big agents being blocked “in the tens and twenties” each week.

Schwab plans to let customers connect AI models through its own Model Context Protocol (MCP) servers instead. MCP is an open standard for plugging AI models into outside data and tools, and Schwab’s version would expose balances and research but not money movement.

The pattern across all five firms is the same: an agent may look at an account through a channel the bank controls, but it may not move money. Axios reported that most banks have authorised or are moving toward read-only access, the same arrangement they already offer budgeting apps such as Quicken.

Why Meta’s Muse brought this to a head

The clampdown follows a rush of consumer AI agents built to act rather than just answer. Meta launched Muse in the US on 8 September 2026 as a personal agent that can fill in forms, send emails, check out on shopping sites and connect to bank accounts, and it added the ability to phone US businesses in a public beta about a week later.

Amazon began blocking Muse on 20 September, saying the agent had not identified itself as AI while browsing. OpenAI released its own agent, Dots, weeks after Muse.

Axios did not name the agents behind the account activity banks are now flagging, and nothing in the reporting ties the call-centre contacts to any specific product.

Security is not the only concern on the table. Bank stocks fell in September as Muse climbed the app download charts, CNBC reported, on fears that consumers would use agents to sweep cash out of low-yielding accounts and into better-paying ones.

JPMorgan CFO Jeremy Barnum raised the same possibility on the October call, and the FT reported that banks have voiced deposit-flight worries to regulators. JPMorgan’s own planned Smart Cash tool, which Dimon said in his April shareholder letter would automate transfers between checking accounts and higher-yielding brokerage products, is designed to do much the same job.

The pushback is spreading north. Bank of Montreal CEO Darryl White told customers not to give AI agents their banking username and password, a day after Royal Bank of Canada CEO Dave McKay said his bank was considering blocking Muse.

Who pays if an AI agent moves your money

The liability question is what turns a terms-of-service breach into a real risk for customers. Barnum said on the earnings call that customers who share credentials with an agent could bear responsibility if the agent misuses their information or makes a transaction they did not want, American Banker reported. Dimon described it to analysts as a transfer of liability.

Federal payment rules may back the banks up. Regulation E, which caps a US consumer’s losses from unauthorized electronic transfers at as little as $50, excludes transfers made by a person to whom the consumer gave their access credentials, unless the consumer has told the bank to stop that person.

The rule defines “person” to include companies, and a January report from the Consumer Bankers Association asked whether handing a password to an AI tool could trigger that exclusion and leave the customer liable for the agent’s mistakes, Payments Dive reported. No regulator or court has settled it.

The safer alternative to password sharing also remains in limbo. The Consumer Financial Protection Bureau’s open banking rule, finalised in October 2024 to move third-party access from credential-based screen scraping to bank-run APIs, has been subject to litigation and reconsideration by the agency’s new leadership since 2025.

For customers already using an AI assistant with a bank account, the practical step is to stop sharing the login itself. A Chase spokesperson told Axios that customers should not give their username and password to anyone. Read-only connections through approved aggregators such as Plaid still work at JPMorgan and Citi, and the CFPB has advised consumers to check whether a connected service can initiate payments and to revoke its access when they stop using it, noting that deleting the app does not cut off the connection.

Banks are now planning for the worst case as well as trying to prevent it. Axios reported that lenders are running “day after” scenarios so they can quickly secure or restore customer access if an agent does damage, and several executives said they know customers will keep wanting these tools and that some middle ground will be needed.

Meta declined to tell Fortune whether Muse’s finance features would survive more banks shutting agents out, and none of the banks have said which agents it detected or how many customer accounts were affected.

One of the keys was the number 4. Google, Mozilla, Apple and Microsoft blocked the certificates between 17 and 20 October, and fixes have since shipped in Go, Python, Node.js, Java and the major Linux distributions, but software that never checks certificate revocation remains exposed until it is updated.

An intermediate certificate authority (CA) is the layer that actually signs the HTTPS certificates websites present, so whoever holds its private key can issue a certificate for any domain that software trusting the CA will accept.

The eight affected intermediates, six for website (TLS) certificates and two for code signing, used P-384 elliptic-curve keys, which should be random numbers more than 100 digits long. Mozilla’s preliminary analysis found every one was a whole number below 256, and security researcher Scott Helme recovered all eight on a laptop in under a second: 4, 56, 66, 115, 155, 156, 230 and 237.

The affected certificates are EM DV TLS CA – G3B and G3C, EM OV TLS CA – G3B and G3C, EM EV TLS CA – G3B and G3C, and the code-signing pair EM OV CS CA – G3B and G3C. The G3B certificates are held by eMudhra BV in the Netherlands, and the G3C certificates by eMudhra Inc in the United States. The six TLS intermediates chain to the emSign ECC Root CA – G3, and all eight also exist as copies cross-signed by Sectigo under its older AAA Certificate Services root, according to the disclosure site run by Mozilla cryptography engineer Dennis Jackson.

Was eMudhra hacked?

This was the most widely asked question, and its answer is NO. Nobody stole the keys; they were generated so badly that they were effectively public from the moment the certificates existed in April 2025. “The key was effectively public from the day the certificate existed,” Helme wrote, noting that a normal CA compromise at least has a thief and a moment of theft to reason about.

eMudhra’s own account, posted on Mozilla’s public bug tracker in Bug 2083449, traces the failure to a key generation ceremony on 30 April 2025 using Utimaco hardware security modules (HSMs).

An approved deviation from its usual script added a key “wrap/unwrap” test because the keys were meant to be exported to US and European data centres for data-sovereignty customers. A flaw in that script created a second, weak set of keys on the HSM, and because the labels were similar, staff used the weak keys to generate the certificate signing requests that eMudhra’s root signed and that Sectigo cross-signed. The company says its RSA issuers followed a different path and are unaffected, that only one of the eight intermediates ever went into production, and that none issued a customer certificate.

The bug thread also shows a warning that was missed. In May 2025, revocation lists (CRLs) that eMudhra signed for the six TLS intermediates failed signature validation, a problem already tracked as Mozilla Bug 1970728. Asked by Jackson how the wrong keys came to sign those CRLs, eMudhra said the lists were first signed with the strong keys it had intended to use, and when the signatures came back invalid, they were re-signed with the flawed keys.

Andrew Ayer, a longtime participant in the forum, confirmed on Mozilla’s dev-security-policy list that the CRLs were indeed signed with the weak keys, which means the mismatch was visible inside eMudhra 17 months before anyone outside noticed.

The discovery itself was mundane. The researcher, credited only as Wayne, wrote on the same list that he found the keys by running Google’s open-source paranoid_crypto weak-key scanner, out of the box, against the Common CA Database (CCADB) as a quick first pass. He has since checked every CCADB certificate without further hits, and said most of his time went on the basics that everyone assumed someone else had already done.

To prove the find, he signed the message “We have a problem here – Wayne” with all eight keys and sent it to the four root programs and eMudhra on Saturday, 17 October.

eMudhra’s 21 October press release, filed with the BSE and NSE, says the researcher found the weak keys could be reverse-engineered “possibly with AI-assisted techniques.” No special technique was required: a key below 256 falls to at most 256 guesses.

Helme did report that an AI agent recovered the keys from a single prompt, but a few lines in any scripting language do the same. The same release says eMudhra’s infrastructure was not compromised, no data was breached, and all physical and logical security controls remained intact, even as the company revoked the eight certificates on 18 October with the stated reason of CA compromise.

How Chrome, Firefox, Apple and Microsoft responded

The browser response was measured in hours. Google’s Chrome Root Program received the report at 18:05 UTC on 17 October, corroborated it and had a CRLSet update blocking the six TLS intermediates in place by 19:45 UTC. Because the block matches each certificate’s public key rather than the certificate itself, it also caught the Sectigo cross-signed copies, and it needed no browser update or restart.

Android devices and Googlebooks received an equivalent block through Google Play Services at around 22:00 UTC on 19 October, and Google says restarting a device pulls it immediately.

Mozilla received the report at 20:06 UTC and finished pushing a OneCRL block to Firefox installations with standard settings at 22:59 UTC, Jackson wrote. eMudhra acknowledged the report that evening and revoked all eight intermediates on 18 October; Apple blocked them on 19 October, Sectigo revoked its cross-signatures the same day, and Microsoft shipped blocks through Windows’ automatic certificate trust list updates on 20 October. Chrome did not need to block the two code-signing intermediates, since its verifier will not build a website chain through a certificate restricted to code signing.

Chrome also confirmed that no website certificate chaining to the six TLS intermediates had been logged to Certificate Transparency (CT), the public ledger browsers require certificates to appear in, before its block. That means no forged certificate from these keys could have been trusted by default in Chrome, Firefox, Edge, Safari or Android apps that enforce CT.

Google says it has checked every other key in its root store and found none with the same weakness, and that CT logs have been updated to reject certificates chaining to the compromised CAs.

The root programs then went further. Mozilla removed the emSign ECC Root CA – G3 from its NSS trust store in version 3.131.1 on 20 October, and Chrome will remove the same root in version 43 of the Chrome Root Store, reaching all devices on the morning of Tuesday, 27 October 2026, Pacific time.

“Due to the seriousness of this incident,” the Chrome Root Program says it is also evaluating whether eMudhra’s remaining root, the RSA-based emSign Root CA – G1, should stay trusted. “This is a serious security incident with implications across the Internet,” Cloudflare said in its own advisory, adding that it has found no active exploitation on its services.

Why the risk outlives the browser fix

Browsers fetch revocation lists on their own and enforce CT. Much of the rest of the internet’s TLS traffic does neither: command-line tools, programming-language libraries, container images, build systems, IoT firmware and server-to-server connections typically trust a bundled list of roots and never ask whether an intermediate has been revoked.

For them, an attacker on the network path, such as a public Wi-Fi operator, could mint an unlogged certificate for any hostname using one of the weak keys, at any time since April 2025.

Helme tested exactly that, forging a certificate for a major payment processor’s API hostname. According to his write-up, curl, Python and Node.js accepted it with default settings on every Linux and macOS machine he tried, and Windows accepted it unless revocation checking was switched on.

The disclosure site also warns that macOS blocks the intermediates for apps using Apple’s own libraries, but the built-in curl, git, python3, perl, ruby and openssl read /etc/ssl/cert.pem, which Apple has not updated and which does not check revocation. Go, cryptography maintainer Filippo Valsorda, flagged git and pip as the most worrying on Bluesky.

“This will be a massive cleanup job, bigger than Heartbleed,” Valsorda told Ars Technica, pointing to IoT devices, Docker containers, forgotten Linux machines and command-line tools that ship their own copy of the roots.

Whether anyone used the keys against such clients during the 17 months they were exposed is unknown, and none of the disclosures offers a way to find out beyond CT searches, which only cover certificates that were logged.

What developers, admins and website owners need to update

For ordinary users, the advice is short: update the browser and operating system and restart. Firefox needs nothing extra unless Remote Settings is disabled by policy, in which case Firefox 158.0.1, ESR 115.43.1 or ESR 153.5.1 carries the block, per Mozilla advisory MFSA 2026-111 (CVE-2026-113470).

Developers have more to do because the fixes take two forms. Some projects block the eight keys directly: Go 1.27.3 and 1.26.10 (CVE-2026-111943) reject any chain containing them in crypto/x509, though programs pick this up only when rebuilt, and Node.js 26.12.1, 24.22.1 and 22.23.4 added the same blocklist on 21 October, along with the NSS 3.131.1 root list. Oracle and OpenJDK shipped matching Java updates, covered in our report on Oracle’s emergency Java fix for the eMudhra CAs. Electron 44.9.1, 43.8.1 and 42.11.16 and Deno 2.9.8 also carry fixes, while Bun’s was still pending on 22 October.

Other projects remove the emSign ECC Root CA – G3 from their bundles instead, which also breaks legitimate certificates under that root: Python’s certifi 2026.10.19, Rust’s webpki-roots 1.0.10, curl’s CA bundle dated 2026-10-20, Homebrew’s ca-certificates, Ubuntu (USN-8944-1 and USN-8944-2), Debian (DSA-6572-1), and Alpine 20261020-r0, with updated packages for Fedora, Arch, Gentoo and FreeBSD listed on the disclosure site.

Red Hat had not shipped packages as of its 21 October bulletin, which rates the issue Important across RHEL 6 to 10, OpenShift and UBI-based containers and offers a manual workaround. PHP teams already working through this week’s PHP2Shell patches should also pull Composer’s ca-bundle 1.6.0 or 1.4.16.

Python needs particular care. Seth Larson’s advisory lists certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1 and pixi 0.82.1 as minimums on Python’s official forum. CPython developer Christian Heimes stressed that pip always loads its vendored certifi bundle alongside the system store, so any pip older than 26.2.2 keeps trusting the compromised intermediates even on a patched OS, and upgrading pip is the only reliable fix. One user found the official Docker python images still shipping pip 26.2.1 on 21 October, so container images need rebuilding.

Anyone can check a client. The disclosure site runs test hosts signed with the compromised intermediates, so running curl https://dv-g3b-emudhra.we-have-a-problem.com/ and curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ should return a certificate error on a protected system; a page load means the client still trusts the weak keys. The site also publishes per-distribution workarounds and a PowerShell script for offline Windows machines.

Website operators have a separate deadline. eMudhra estimates about 30,000 customer certificates are chained to the emSign ECC Root CA – G3, and Google says sites using them must install a certificate from another hierarchy before the 27 October Chrome removal to avoid errors. eMudhra says it has stopped issuing under that root and will replace affected certificates free of charge.

Does this affect Indian DSC, eSign and government websites?

The compromised certificates belong to eMudhra’s global emSign hierarchy, not to the Root Certifying Authority of India chain it uses to issue the Digital Signature Certificates (DSCs) needed for tax and company filings, or to its eSign service.

Both are regulated by the Controller of Certifying Authorities (CCA) under the Ministry of Electronics and Information Technology (MeitY), and eMudhra says they run on completely separate infrastructure and are operating normally.

MeitY has formed a special team to investigate, senior officials told ThePrint on 21 October, adding that the impact on Indian websites and applications “has been very limited and for a very short period.”

The same day, CERT-In issued advisory CIAD-2026-0050, which says the public disclosures do not establish confirmed malicious use of the keys and warns that removing the root could leave legitimate sites untrusted. eMudhra issues TLS certificates to businesses and government agencies, including for some public services such as India’s income tax portal, Reuters reported.

The Internet Freedom Foundation (IFF) has written to eMudhra, CERT-In and MeitY asking for a dated incident report, an independent audit by an auditor eMudhra has not used before, and confirmation of whether the company reported the incident within the six hours CERT-In’s 2022 Directions require.

IFF notes that eMudhra has told Mozilla a separate “A” and “A-1” series of intermediates was meant for deployment only in India, and argues that subscribers have no independent basis yet for accepting that the licensed hierarchy is untouched. It found no statement from the CCA.

Why eMudhra is quitting the global TLS business

eMudhra’s exit announcement quotes chairman V. Srinivasan saying the company revoked the affected CAs within 14 hours of discovery and disclosed promptly. He said global SSL/TLS brings in about 1% of revenue, that rising compliance and data-sovereignty costs and competitors issuing certificates for free had already eroded its returns, and that social media amplification had brought scrutiny “out of proportion to SSL/TLS’s place in our business.”

Investors reacted sharply. eMudhra shares fell 20% on 21 October and about 40% over the two days after disclosure, Business Standard reported, citing Reuters. The company says its emSigner, SecurePass, CertiNext and enterprise PKI products are unaffected.

The wind-down plan leans on infrastructure that is itself under review. eMudhra says its G1 RSA roots will keep serving customers until the transition is complete, that revocation and status services will run until every issued certificate expires or is replaced, and that it will still deliver a full root-cause report to the browser root programs. Chrome’s evaluation of that same emSign Root CA – G1 has not concluded.

What happens next turns on three open items: eMudhra’s final root-cause report, Chrome’s decision on the G1 root, and whether CERT-In or the CCA publishes findings of its own.

On the industry side, participants on Mozilla’s policy list are already pushing for mandatory HSM key attestation, which would let a CA prove a key was generated inside the hardware, through an IETF draft that is close to completion. Whether the weak keys were ever used against software outside the browser during their 17 months in the open may never be known.

The release, posted to GitHub by a researcher using the handle rafalohaki, was posted on X on 22 October, describes a “pure logic bug” that the author says is separate from the two memory-corruption flaws the patch addressed, with a demo showing a one-shot HTTP request returning a shell as uid=33(www-data) on Debian 13.

The claim lands in the middle of the largest PHP security scramble in years, but it is narrower than the headline suggests, and the researcher says so plainly. The repository states the technique against 8.5.12 depends on “session gaps” and specific conditions, and a second chain, it demonstrates — session-file poisoning to local file inclusion to RCE on PHP 8.5.11 — is described by its own author as “an application flaw, not a PHP core bug.”

What the new PoC actually does

The original PHP2Shell bugs sit in the PHP engine itself, so any site running a vulnerable interpreter is exposed regardless of its own code. The patch bypass that is being circulated is a different kind of thing.

According to the repository, the 8.5.12 exploit abuses the way PHP handles session state between requests — poisoning a session key that persists in a session file, then triggering it through a handler that processes PHP — rather than the out-of-memory corruption (CVE-2026-109618) or stale global state (CVE-2026-109619) that the official release fixed.

According to the repo, the list of conditions the target has to meet includes several sinks that do not work: a session ID containing .php is rejected because PHP validates the session id, php://input via include fails because allow_url_include is off by default and deprecated in PHP 8, and error-log poisoning fails because PHP HTML-encodes the payload.

The author frames the work as research over public PHP code and a demonstration of specific, conditional chains, not a drop-in exploit that turns every 8.5.12 server into a shell. As of 22 October 2026, the claim had not been independently reproduced or confirmed by the PHP security team, and PHP has not issued a further advisory in response.

A working bypass of the official fix for a bug this widespread would be severe; a conditional, configuration-dependent chain and a separate application-level LFI are serious but far smaller in blast radius. Both descriptions have been circulating under the same “patched PHP still vulnerable” framing, and only the first would justify the alarm.

Attackers were already probing before anyone knew

The bypass claim arrives on top of evidence that exploitation of PHP2Shell began before the public ever heard the name. Amazon’s threat-intelligence team reported on 21 October that its MadPot honeypot network recorded a PHP2Shell exploitation attempt on 17 October, four days before disclosure, from an IP address tied to a commercial anonymisation network.

“The exploit attempt originated from an IP address associated with a commercial anonymization network,” wrote CJ Moses, CISO of Amazon Integrated Security, who added that it is unclear how the actor obtained exploit details while the flaw was still under embargo.

In the hours around the 14:00 UTC embargo lift, it saw multiple proof-of-concept exploits — the earliest around 02:00 UTC — and attempts from varied infrastructure and payloads that suggested several actors, not one. The company argues the gap between patch and working exploit is collapsing because AI-assisted analysis makes turning a patch diff or advisory into an exploit cheaper, so defenders should measure patching for critical internet-facing bugs in hours, not days, and investigate from the earliest known exploitation date rather than the disclosure date. For PHP2Shell, Amazon says, that means starting from at least 17 October.

Cloudflare’s chief executive, Matthew Prince, said on X that attackers had made millions of exploitation attempts since disclosure, and the company’s CTO, Dane Knecht, said Cloudflare watched attackers change payloads to slip past its first mitigation rules. Even so, officials in Germany, the Netherlands and Japan have said none of the attempts appears to have succeeded. “At the moment it doesn’t look like exploitation has taken off or been widespread,” Ryan Austin, a Calif researcher who helped find the flaws, told the Guardian.

Where the panic outran the facts

The PHP2Shell story has also generated claims that do not hold up against the primary sources. Posts on X this week described an internet “lockdown,” a coordinated wave of government, bank and hospital shutdowns, and a wave of breaches branded “Black October.”

The precautionary shutdowns were real and widespread — Dutch and Finnish government services, French prefecture sites, several German state and city portals, and banks and airlines in Japan and Nepal all took systems offline as a precaution while they patched — but they were preventive, not the result of confirmed compromise. No successful break-in has been publicly confirmed.

The same gap between rumor and record shaped the disclosure itself. The flaws leaked a day early after an anonymous Hacker News post citing a trusted tip went up and came down on 20 October, screenshots of a leaked exploit tool credited to Calif spread to X and Mastodon, and Calif itself briefly posted a proof-of-concept video.

In the rush, a single php.ini setting — disabling session upload progress — circulated as the fix; GMO Flatt Security, which suggested it, later said it was not enough on its own, and PHP’s own advisory is blunt that there is no complete mitigation short of updating.

OpenAI, which helped discover the original flaws under its Patch the Planet program and called them “one of the most impactful security issues in recent memory,” has published a checker as two Codex skills that test whether a URL or a local PHP binary is on a vulnerable version. Its documentation carries a warning worth repeating in light of the bypass claims: an “UNKNOWN” result does not mean the target is patched.”

What to do

Nothing in the bypass claim changes the baseline advice, and the fix for the core flaws remains the priority. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package, then restart PHP-FPM, Apache and any long-running workers so the old code stops serving requests.

Branches 8.1 and older get no release from php.net, so those still on 8.1, 8.0 or 7.4 need a vendor or source backport as a bridge and a plan to move to a supported branch. On the new PoC specifically, the mitigations that reduce exposure — keeping allow_url_include off, letting PHP validate session IDs, and auditing application code that includes files built from user-controlled input — are standard hardening already in place on most correctly configured servers.

The researcher behind the bypass has not released a universal exploit, PHP has not confirmed the claim, and no breach using it has been reported. What the past 48 hours have established is narrower and more durable than any single PoC: with the core advisories now public and exploit development accelerating, the window between a PHP patch and a working attack against the servers that ignore it is measured in hours.

Here’s a stat that should keep IAM architects up at night: 79% of organisations have already shoved AI agents into production without a single written policy governing them, according to a 2025 EMA survey conducted in conjunction with Ory. 

And the machines are multiplying fast: Eighty-three per cent of large enterprises and 70% of mid-sized ones are already running agents in the wild, and up to 98% plan to join the party soon, according to the same source.

Meanwhile, non-human identities have surged to a mind-bending 144:1 ratio over human identities, a 44% increase from the 92:1 ratio observed in H1 2024, based on Entro Labs research. Gartner sees the trajectory clearly: 40% of enterprise applications will embed task-specific AI agents by the end of 2026, rocketing up from under 5% in 2025. That’s not a trend. That’s a hockey stick.

And yet most IAM stacks are hopelessly unprepared. 61.6% can’t handle the security demands. 62.0% buckle under the scale. 48.7% are unprepared for compliance. 59.4% lack the resiliency needed when something goes sideways, according to the same EMA survey. 

If you’re running thousands of agents, each one authenticating, grabbing tokens, calling tools, chaining actions, your human-scale IAM isn’t just slow. It’s actively dangerous.

What you need is an IAM built for machine speed. Token issuance that doesn’t blink. Zero-trust enforcement without static secrets sprawled across config files. MCP-native authentication that understands agent-to-tool flows. And the ability to kill a rogue agent’s access in seconds, not hours or days.

To cut through the noise, we evaluated the top 7 enterprise agent IAM platforms using the criteria below.

How We Evaluated: Methodology & Criteria

We’re not just throwing darts at a vendor list. Every platform here was assessed against five criteria that matter when you’re fielding 1,000+ AI agents and your existing IAM is already wheezing.

1. Machine-Scale Token Issuance – Can the platform handle authentication and authorisation at the speed and concurrency thousands of autonomous agents demand? No human-scale bottlenecks allowed.
2. Fine-Grained Authorisation & MCP Support – Out-of-the-box RBAC, ReBAC, Zanzibar-style permissions, plus native Model Context Protocol authentication for agent-to-tool flows. If your agents can’t securely call MCP servers, you’re just building a very expensive chatbot.
3. Deployment Flexibility – Self-hosted, on-premises, private cloud, or fully managed. Data residency and compliance postures aren’t negotiable, and neither should your deployment model.
4. Zero-Trust Enforcement for Non-Human Identities – Just-in-time access, short-lived credentials, cryptographic identity. No static secrets lying around waiting to be exfiltrated. And yes, a kill-switch for agents that go rogue.
5. Governance, Visibility & Lifecycle Management – Agent onboarding, ownership assignment, deep observability for agents connected to or built on Ory, policy enforcement down to the tool-call level, and audit trails that hold up under scrutiny.

These five criteria align directly with what EMA’s research identifies as the top IAM priorities for agentic AI: Security, Scalability, Visibility, and Resiliency. 

Now, let’s get to the ranking.

1. Ory – The API-First Agent IAM Built for Machine Scale

Here’s the thing most IAM vendors won’t tell you: they built their platforms for humans first, then tried to bolt agents on afterwards. Ory didn’t. It’s open-source background, API-first, and architected for machine scale from day one.

The numbers are frankly staggering. Ory’s infrastructure manages 3.25 billion identities and processes 4.4 billion transactions per day across 33,000+ production deployments. It’s crossed 700 million downloads, and Docker pulls. 

And if you’ve ever wondered who handles authentication for OpenAI’s hundreds of millions of weekly active users. It’s Ory. OpenAI adopted the self-hosted Ory Enterprise License for Ory Hydra’s web-scale authorisation, enabling unprecedented logins per second with levels of data transparency and infrastructure flexibility not possible with other vendors. 

ChatGPT reached 1 million users in just five days, surpassed 100 million monthly active users by January 2023, and by February 2026, its user base had grown to approximately 900 million weekly users. That’s machine scale, proven in the most unforgiving production environment imaginable.

What does this mean for your agent fleet?

• Machine-scale token issuance: Ory Talos is built on the same high-concurrency Go architecture as Ory Hydra, which powers OpenAI’s more than 900 million weekly active users, and is designed to handle the authentication throughput that large-scale agentic workflows demand. Ory Hydra and Ory Talos don’t sweat when your agents hammer it for tokens. It was designed for exactly that.
• Fine-grained authorisation & MCP support: RBAC, ReBAC, Zanzibar-style permissions via Ory Keto. Native MCP authentication. Full OAuth and OIDC standards compliance. And everything runs headless and API-first; there’s no UI to render for agent identities, because agents don’t need a login page.
• Deployment flexibility: Self-hosted. On-premises. Private cloud. Fully managed via Ory Network. This directly serves the 72.1% of organisations that prefer self-managed LLM deployment (on-premises or private cloud), which correlates with a stronger preference for self-managed IAM solutions. You choose the model; Ory adapts.
• Zero-trust enforcement that actually means something: Ory Talos, launched in 2026, transforms traditional static API keys into programmable, hardened identities using Macaroon-based delegation and token derivation. If a child token gets stolen, it expires in 15 minutes (you set the timeframe). You control precisely what agents can access, for how long, and from where. No more “set it and forget it” secrets.
• Ground-up observability and true composability: Trace-level log correlation, performance intelligence baked in. And because Ory is modular, you can deploy Ory Kratos, Ory Hydra, Ory Keto, and Ory Talos independently; you’re never locked into a monolithic stack you can’t reconfigure.
• Ory Agent Security: Ory’s dedicated agent security layer provides a unified control plane for onboarding workflows, ownership assignment, behavioural observability, and an immediate kill-switch for rogue agents. Unlike bolt-on agent monitoring tools, it is native to the Ory stack, meaning policy enforcement and audit trails flow through the same infrastructure already handling billions of daily transactions.

Ory carries a 4.5 out of 5 average rating on G2 in Identity and Access Management Software based on 52 reviews. It is backed by Insight Partners, Balderton Capital, PHX Ventures, and IQT. 

Best for: Ory is the top choice for enterprises running thousands of AI agents that demand self-hosted, composable, machine-scale IAM with full API-first control. It’s also the right call if you want to enforce policy where agents actually execute actions. Ory is one of the few vendors that secures agents at the point of execution through Ory Agent Security.

Less ideal for: Organisations that require a fully-managed SaaS with minimal engineering overhead, though Ory Network offers a managed path, the tooling remains developer-first, and the configuration learning curve is real.

2. Aembit – The Independent Identity Broker

Aembit is an independent identity broker securing access for AI agents, MCP servers, and workloads across clouds, SaaS, and on-premise data centres using policy-based, secretless, just-in-time access with blended human-agent identity and real-time policy enforcement. 

Think of it as the diplomatic layer, authenticating agents, evaluating contextual policies, and brokering credentials across cloud, SaaS, and on-premises environments without ever touching a static secret.

Its MCP Identity Gateway handles agent-to-MCP-server authentication specifically. If you’ve already got your IDPs in place but lack a secure way for agents to talk to tools, Aembit fills that gap neatly.

• Core capabilities: Secretless, just-in-time access brokering with policy-based contextual evaluation. Blended human-agent identity for workflows where both interact. A dedicated MCP Identity Gateway purpose-built for agent-to-tool authentication.
• Strengths: Clean separation of concerns. Aembit brokering atop existing IDPs means no rip-and-replace. Its workload IAM pedigree translates directly to agent use cases without reinvention.
• Limitations: It’s not a directory or identity provider. If you need native identity management, authentication, and full lifecycle governance under one roof, you’ll need complementary platforms.

Best for: Ideal for teams already deep in workload IAM who need a broker layer to extend secure access to AI agents without disrupting their current identity stack. 

Less ideal for: Organisations starting from scratch who want a unified platform covering identity creation through governance.

3. Teleport – Cryptographic Identity for All Identities

If you’re the sort of organisation where “who accessed what and when” isn’t just a compliance checkbox but an existential requirement, Teleport speaks your language. It unifies human, machine, and AI identities through cryptographic certificates and ephemeral privileges, claiming a 95% reduction in exposed attack surface with 100% auditable agentic workflows.

There are no shared secrets in Teleport’s model. A hardware root of trust issues cryptographic identities, and every session, agent included, gets recorded. Zero standing privilege means even if an agent is compromised, it has nothing to steal.

• Core capabilities: Cryptographic identity issuance via hardware root of trust. Ephemeral, zero-standing-privilege access. Full session recording and audit trails for agentic workflows. MCP tooling integration.
• Strengths: The infrastructure-first security model eliminates credential theft vectors entirely. It’s used by international stock exchanges and fintech leaders who demand immutable audit trails.
• Limitations: Teleport is infrastructure-native, not SaaS plug-and-play. Organisations wanting out-of-the-box agent discovery dashboards and turnkey lifecycle management may need more engineering effort than anticipated to operationalise.

Best for: Best for fintech, stock exchanges, and heavily regulated verticals where infrastructure access boundaries and auditability are paramount. 

Less ideal for: Teams prioritising a lightweight SaaS experience with built-in agent discovery and governance tooling.

4. Idira by Palo Alto Networks – Modern PAM Meets Agentic Identity

Idira by Palo Alto Networks (formerly CyberArk) launched May 12, 2026, as a next-generation identity security platform built on CyberArk’s PAM heritage, integrating modern PAM, machine identity security, and agentic identity security in one platform. 

Features include zero standing privilege, just-in-time enforcement, AI-driven discovery, agent-to-MCP-server governance, and lifecycle management for human, machine, and agentic identities. The timing matters; this is PAM’s heritage meeting agentic identity head-on.

Idira’s 2026 Identity Security Landscape report, drawing from 2,900+ cybersecurity decision-makers worldwide, found that machine identities now outnumber humans 109:1 and that 9 out of 10 organisations suffered a successful identity-related breach in the past year. 

Those figures underscore why a platform that bakes modern PAM, machine identity security, and agentic identity into one roof matters.

• Core capabilities: Idira’s Secure AI Agents offering includes agent discovery, MCP server registration, and an identity broker governing access to MCP servers; the platform delivers modern PAM with zero standing privilege and just-in-time enforcement across all identities (human, machine, agentic). An AI-driven discovery engine.
• Strengths: Deep PAM heritage means least-privilege and just-in-time access aren’t bolt-ons; they’re baked into the DNA. For organisations already running Palo Alto Networks or CyberArk estates, Idira is the natural extension.
• Limitations: Integrated suite architecture means less composability. You’re buying into the Palo Alto Networks way of doing things. Teams wanting open-source, API-first building blocks with modular swapping will find Idira more prescriptive.

Best for: Ideal for large enterprises already invested in the Palo Alto Networks ecosystem that need to extend the mature PAM discipline to thousands of AI agents. 

Less ideal for: Teams prioritising lightweight, composable, open-source building blocks over integrated suite cohesion.

5. SailPoint Agentic Fabric – Governance-First Agent Identity

SailPoint takes everything it knows about identity governance and extends it to the agentic workforce. The Agentic Fabric provides continuous discovery of AI agents and non-human identities, a unified identity graph, ownership assignment, and least-privilege policy enforcement down to the MCP tool-call level.

This governance-first approach directly addresses a painful reality: 60.5% of organisations still manage agents through a hybrid human/service account model, while 23.6% manage agents purely as service accounts and 10% manage them as human identities, rather than through dedicated agent identity frameworks. That’s duct tape and hope, not a strategy.

• Core capabilities: Continuous agent and NHI discovery. A unified identity graph with ownership assignment. Access certification and least-privilege enforcement at the MCP tool-call level. Real-time automated response. An MCP Server for Identity Security Cloud customers. Integration with AWS, Azure, GCP, Salesforce, and Microsoft Copilot Studio Agent.
• Strengths: SailPoint’s governance pedigree is highly regarded in the agent IAM space. Compliance-driven enterprises get access certification, audit trails, and policy enforcement they already trust. The August 2026 launch unified human, non-human, and AI agent identities under one security model.
• Limitations: The governance-first model adds overhead. Lean engineering teams may find it heavy going. Organisations wanting a lightweight, developer-oriented, entirely self-hosted solution without the governance apparatus may chafe.

Best for: The go-to for compliance-driven verticals, financial services, healthcare, insurance, where access certification and auditable policy enforcement are non-negotiable. 

Less ideal for: Teams prioritising developer velocity and self-hosted composability over governance machinery.

6. Microsoft Entra Agent ID – The Ecosystem Extender

Microsoft Entra Agent ID extends the Entra identity backbone to AI agents through agent identity blueprints with parent-child policy inheritance, OAuth 2.0, MCP, and A2A protocol support. 

It works with both Microsoft and non-Microsoft platforms, AWS Bedrock, n8n, and others, though the deepest integrations naturally live inside Azure.

Available to all Microsoft Entra customers, advanced features require a Microsoft Agent 365 license.

• Core capabilities: Agent identity blueprints with parent-child policy inheritance. OAuth 2.0, MCP, and A2A protocol support. Conditional access extended to agents. Lifecycle governance with audit trails. Cross-platform reach, including AWS Bedrock and n8n.
• Strengths: Massive existing install base. Azure-centric enterprises can weave agent identity into their existing Conditional Access and governance fabric with minimal new tooling. Blueprints provide a clean policy-inheritance model.
• Limitations: Deep Microsoft ecosystem integration means multi-cloud organisations running heterogeneous stacks may encounter friction. Advanced features are gated behind the Microsoft Agent 365 license, adding cost at a time when 51% of organisations already cite rising IAM costs as their biggest challenge.

Best for: The path of least resistance for Azure-centric enterprises that want agent identity slotted into existing Conditional Access policies. 

Less ideal for: Genuinely multi-cloud, vendor-neutral stacks that chafe at ecosystem gravity.

7. Okta for AI Agents – Identity-First, Vendor-Neutral

Okta for AI Agents became generally available on April 30, 2026, delivering agent discovery, onboarding into Universal Directory, short-lived credential enforcement, and a kill-switch for rogue agents, all in a vendor-neutral package.

The Agent Gateway governs MCP server access regardless of the agent’s build platform, and Okta actively contributes to the OpenID-JAG standard. 

That commitment to interoperability matters when you’re dealing with the IAM fragmentation that plagues most enterprises: organisations already use an average of three IAM platforms (including CIAM solutions), with 34% using four or more, and 47% worry about rising or unpredictable costs.

• Core capabilities: Agent discovery and registration into Universal Directory. Short-lived credential enforcement. Agent Gateway for MCP server governance across build platforms. Lifecycle management with a kill switch. Active ID-JAG standards contribution.
• Strengths: Market-leading IAM with native agent identity features that don’t feel bolted on. The vendor-neutral posture and open-standards commitment appeal to heterogeneous enterprises. The kill-switch provides a genuine operational safety net.
• Limitations: Predominantly SaaS-delivered. Organisations requiring on-premises or self-hosted deployment won’t find a native path. And Okta’s platform breadth can mean higher per-agent costs at scale compared to open-source alternatives.

Best for: The strongest vendor-neutral SaaS option on this list for organisations comfortable with SaaS delivery and Okta’s pricing model. 

Less ideal for: The 72.1% of organisations that prefer self-managed IAM, or for cost-conscious enterprises where per-identity pricing at machine scale gets uncomfortable fast.

The Reality Check: Gaps, Costs, and Fragmentation

Before you pick a platform, let’s get real about the state of enterprise IAM. The stats below are from the same 2025 EMA survey cited earlier.

Fifty-eight per cent of organisations are juggling three or more IAM solutions, and 51% cite rising costs as their biggest challenge with IAM deployments; approximately 68% are looking to bring their IAM deployment in-house instead of relying on SaaS. Adding a separate agent IAM could compound both fragmentation and budget pressure simultaneously.

Approximately 52.8% of organisations want an all-in-one IAM platform, but only 24% have achieved one. Most still stitch together best-of-breed components, and agent IAM adoption will widen that gap unless platforms consolidate human and agent identity effectively.

The self-hosting preference is also striking: 72.1% favor self-managed LLM deployment, which correlates strongly with appetite for self-hosted IAM (68.2%). That preference directly shapes this ranking.

Then there are the operational silos. On average, organisations report three teams own the security and compliance issues around agentic identity, with the most frequently cited teams being IT/Security, Identity/IAM Teams, and Development/Engineering Teams — a multi-team approach that creates potential operational silos.

In financial services specifically, only 29.7% of financial sector organisations have agentic AI running externally at scale in production versus 40.6% in the broader market; 64.8% of financial organisations remain in limited deployments or pilot programs. 

Yet 67.6% of financial sector organisations express a strong preference for an all-in-one SaaS IAM platform, compared to 50.4% across other sectors. — a tension between readiness and appetite that any vendor strategy needs to acknowledge.

The bottom line: no single platform covers every edge case. Evaluate based on your top priority, EMA’s ranked list is Security, Scalability, Visibility, and Resiliency, and your deployment model preference before committing.

Final Take: The Agent IAM Stakes Are Rising

The numbers don’t leave much room for debate. Non-human identities are exploding at a 144:1 ratio over human identities. Gartner predicts 40% of enterprise apps will embed task-specific AI agents by the end of 2026. Purpose-built agent IAM isn’t a nice-to-have; it’s an operational survival requirement.

Anchor your evaluation on clear criteria. The five we applied are a defensible starting point and a realistic assessment of your deployment model, governance burden, and tolerance for engineering overhead. 

The market is moving fast. Keep watching developments in MCP standards, delegate-token hardening like Ory Talos’s Macaroon model, purpose-built control planes like Ory Agent Security, and the emerging OAuth-for-agents specifications. Because the best platform today may not hold the crown in 12 months, and with thousands of agents already running in your infrastructure, you can’t afford to wait.

Tracked as CVE-2026-94300 with a CVSS score of 8.1, the flaw sits in BIND’s handling of GSS-TSIG, a Kerberos-based authentication layer for DNS transactions. According to ISC’s advisory, it affects every BIND release from 9.11.0 onward: versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.29 and 9.21.0 through 9.21.26, along with Supported Preview Edition builds 9.11.3-S1 through 9.18.50-S1 and 9.20.9-S1 through 9.20.29-S1.

ISC fixed the issue in BIND 9.20.30, 9.21.27 and 9.20.30-S1. The organization said it is not aware of any active exploitation, and no workaround exists.

Japan Registry Services (JPRS), operator of the .jp registry, labelled the bug urgent on Thursday, warning of both DNS service disruption and remote code execution and strongly recommending an immediate upgrade. The Canadian Centre for Cyber Security also issued an alert (AV26-1072) covering the release.

How does the BIND GSS-TSIG vulnerability work?

TSIG, defined in RFC 8945, adds a digital signature to DNS messages so a server can verify who sent them. GSS-TSIG, defined in RFC 3645, connects TSIG to the GSS-API so those signatures can rely on Kerberos. It is most often used for authenticated dynamic DNS updates in networks that integrate BIND with Active Directory.

When a client and server set up a GSS-TSIG session, they negotiate a key through the TKEY mechanism and name shares that session across every message signed or verified with the key.

According to Linux Compatible, concurrent signed messages could corrupt that shared Kerberos state, and the fix, tracked as ISC GitLab issue #6320, serialises access to it.

ISC describes the attack as a replay. An attacker who captures a previously signed UDP message can resend it while the negotiated key is still valid, which can corrupt memory in named and abort the process. If the attacker also sends crafted queries to a zone they control, the corruption can potentially be turned into remote code execution. The CVE record classifies the bug as a race condition (CWE-362) and a double free (CWE-415).

Attack complexity is rated high because the attacker must obtain a legitimately signed message and act within the key’s lifetime. No privileges or user interaction are required, however, and a successful attack has a high impact on confidentiality, integrity and availability.

ISC said it found the bug during internal testing, and credited Dave Aitel of OpenAI with independently discovering and reporting it. ISC sent early notification to its support customers on October 14 and published the advisory on October 21.

Which BIND versions should be updated?

Operators who build BIND from source should move to 9.20.30 on the stable branch or 9.21.27 on the development branch. JPRS advised anyone using distribution packages to follow their vendor’s updates and apply them as soon as they are available.

Debian has already shipped the fix for Debian 13 “trixie” in bind9 1:9.20.30-1~deb13u1, released under advisory DSA-6576-1, which also covers the three other BIND vulnerabilities patched this month.

BIND 9.18 users will not get a patch. That branch reached end of life in June with version 9.18.50. ISC does not ship security fixes for unsupported branches, so the only remedy is migrating to 9.20.

The same release fixes three other high-severity denial-of-service bugs, each rated 7.5. CVE-2026-19630 lets crafted inbound messages with excessive name compression make named burn CPU and memory, which can starve busy resolvers. CVE-2026-96888 crashes resolvers that combine a redirect zone with strict QNAME minimisation. CVE-2026-97313 causes named to exit on recursive servers that hold conflicting response policy zone (RPZ) settings. ISC credited researcher Vitaly Simonovich with the last two.

Why is BIND getting so many security updates?

This is ISC’s fourth consecutive monthly BIND security release. In May, the organisation warned that large language models were making flaws in open-source code much easier to find. It said it was triaging vulnerability reports at a rate that “exceeds 10X the historic levels.”

ISC responded by putting security fixes in every monthly maintenance release and delaying the next stable branch, BIND 9.22, to at least the end of 2026. The September release alone fixed 14 vulnerabilities. ISC has said it hopes to return to quarterly releases in the first quarter of 2027.

The issue is tracked as CVE-2026-91403. Oracle rates it critical, with a CVSS score of 9.1. It sits in the JSSE component, Java’s TLS implementation, and an unauthenticated attacker can exploit it over the network. Oracle’s advisory does not describe the root cause. The OpenJDK advisory, published the same day, does: the CVE concerns eight compromised intermediate CA certificates.

Affected releases are Oracle Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1, Oracle GraalVM for JDK 17.0.21 and 21.0.13, and GraalVM Enterprise Edition 21.3.20. Oracle said earlier that unsupported versions are likely affected as well.

The certificates belong to eMudhra, the Bengaluru-based certificate authority that sells TLS certificates under the emSign brand. eMudhra created the eight Global TLS intermediates during a key generation ceremony in April 2025. A flaw in that process left them with cryptographically weak keys. One intermediate’s private key was simply 4. The other seven were small numbers ranging from 56 to 237.

An intermediate CA signs the certificates that websites present. Anyone holding one of these keys could therefore mint a certificate for any domain, and clients that trust the chain would accept it. Mozilla said the keys let attackers “issue fraudulent HTTPS certificates for websites they do not control”. An attacker who could intercept a connection could then impersonate a site and read or alter its traffic.

Oracle’s notes say the Java flaw can be exploited through APIs in the component, such as a web service that supplies data to them. It also applies to sandboxed Java Web Start applications and applets that load untrusted code.

The compromise came to light on the weekend of October 17. Chrome’s root program received the report at 18:05 UTC on Saturday and landed a CRLSet block on the affected intermediates within two hours. Mozilla blocked them through OneCRL the same evening. Apple followed on October 19 and Microsoft on October 20.

A summary site run by Dennis Jackson credits the original report to a researcher identified as Wayne. BleepingComputer reported that researcher Flüpke published one of the keys on GitHub.

eMudhra said it revoked all eight intermediates on October 19, and that the incident does not affect its root CA private keys or its other intermediates. The company said most of the certificates were never used in production. It found no evidence they had issued certificates to end users. It has also stopped issuing new certificates under its G3 root.

Google is going further. Chrome plans to remove the emSign ECC Root CA – G3 root on October 27. Google told sites with certificates chaining to that root to replace them right away with certificates from another CA.

Java is not the only runtime to ship a fix. Go released versions 1.27.3 and 1.26.10 for the same issue, tracked as CVE-2026-111943. Python certifi, Electron, pip, rustls-webpki and the major Linux ca-certificates packages have also been updated.

Oracle customers should install the patched build listed in the Java SE patch availability document linked from the alert. OpenJDK advises users of standalone runtimes to update as soon as possible. Until then, they can block the certificates manually by replacing the blocked.certs file in the JDK’s lib/security directory. OpenJDK packages shipped by Linux distributions such as Debian, Fedora, RHEL and Ubuntu usually rely on the system’s certificate store. For those, updating ca-certificates is sufficient.

The patched builds are Node.js 26.12.1, 24.22.1 and 22.23.4. According to the project’s advisory, the Brotli flaw, CVE-2026-111497, is an out-of-bounds write in the decoder and affects all three lines. Node.js did not publish CVSS scores for any of the 10 issues, and its advisory does not describe how the Brotli bug is triggered.

Matteo Collina reported the Brotli flaw, and Antoine du Hamel fixed it by cherry-picking an upstream Brotli commit authored by Evgenii Kliuchnikov.

Imperva researcher Ron Masas published an analysis on Thursday that names the flaw Node2Shell. Imperva said its proof of concept ran attacker-supplied code in applications using the official Node.js 24.22.0 Linux arm64 image, and that Node.js 24.22.1 rejected the same inputs.

The code arrived inside Brotli-compressed data, either in a response consumed by Node.js’s built-in fetch() or in a request body decoded by Express 5.0.0 to 5.3.0 or body-parser 2.0.0 to 2.3.0. Imperva said execution took multiple attempts in its setup, and that it tested only Linux arm64 builds and its own application configurations.

According to Imperva, the vulnerable decoder could continue past a block transition that the stream’s own structure made impossible, treat it as a request for more input, and carry on with an invalid internal state, which led to the out-of-bounds write. The upstream Brotli fix makes the decoder return a format error instead. Imperva said a bare Node.js HTTP server does not decode incoming Brotli bodies on its own, so exposure on the request side depends on middleware such as Express 5 or body-parser being configured to decompress them.

Imperva said it has added WAF rules for the flaw. It advised limiting untrusted Brotli traffic on affected paths while updates roll out, but said only a Node.js update fixes the decoder.

Three of the 10 flaws sit in TLS hostname verification. CVE-2026-105483 (high, 26.x and 24.x) covers a certificate hostname bypass when an IP address is written in full-width digits. CVE-2026-106069 (high, all three lines) covers a bypass that occurs when a host resolves to an IP address, and CVE-2026-106072 (medium, all three lines) lets DNS names in a certificate authenticate IP endpoints when the IPv4 hostname is non-canonical.

The advisory titles describe a common pattern: an address written in an unusual form is not recognised as an IP, so the certificate check falls through to the DNS names, and a certificate issued for a domain name can vouch for a connection to an IP endpoint. The fixes make TLS reject non-canonical IP addresses and correct an IP normalisation regression.

The fourth high-severity bug, CVE-2026-105482, affects all three lines. dns.resolve truncates names that contain a NUL character, and Node.js now validates resolve inputs for null bytes. The same researcher, hasanfleyah, reported that flaw, the fullwidth-digit TLS bypass and a medium-severity HTTP bug, CVE-2026-105481, in which a keep-alive socket processes a response that was written before the request was sent. James Snell fixed all three.

A second medium-severity flaw, CVE-2026-106074, affects applications that use startup snapshots or single-executable applications. The entropy caches behind crypto.randomUUID() and randomInt() were saved into the snapshot, so every process started from it repeats the same values. Node.js now resets the caches across snapshots.

The three low-severity issues are CVE-2026-106073, a Permission Model bypass through fs.realpathSync that affects all three lines, and two that affect only 26.x: CVE-2026-106071, a filesystem over-grant in the Permission Model through a wildcard lookup, and CVE-2026-106070, where the ZIP reader returns attacker-controlled prefix bytes after a failed header validation.

The releases also deal with the eMudhra certificate authority compromise. Mozilla said it received a report on Saturday, 17 October, that private keys for eight eMudhra intermediate certificates had been compromised, which could let attackers issue fraudulent HTTPS certificates for sites they do not control. eMudhra said in its statement that the affected intermediates came from a key generation ceremony held in April 2025 and that its investigation is ongoing.

All three Node.js releases now reject TLS chains that contain blocked public keys and update the bundled root certificates to NSS 3.131.1, the Mozilla trust store release that removes the root that signed the affected intermediates. The security release also updates c-ares to 1.34.9 on every line, OpenSSL to 3.5.9 on 24.x and 22.x, SQLite to 3.53.4 on 22.x, and undici on all three lines.

Node.js notes that end-of-life versions are always affected when a security release ships, so servers outside the three supported lines have no fix. Imperva said the services most at risk are those that decode Brotli from outside their trust boundary, and that teams should check the Node.js version inside container images, since a package inventory can miss a bundled runtime. Teams that distribute snapshots or single-executable apps should check whether those need rebuilding with a patched runtime.

PHP shipped fixes for its two critical PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Update:

2026-10-23: Added Imperva’s Node2Shell analysis, which reports a working remote code execution proof of concept against Node.js 24.22.0. Imperva’s post does not report exploitation in the wild.