October 2026 was a rough month for internet security. Within a few days, two high-impact incidents were disclosed. One hit one of the most widely deployed web runtimes. The other hit the trust system that HTTPS depends on. Many customers have asked whether Afi is affected, so here is a direct answer.
Afi does not run PHP anywhere in its platform, and none of our certificates were issued by eMudhra / emSign. No action is required from Afi customers for either incident.
PHP2Shell: two critical PHP RCE vulnerabilities
Researchers from Calif.io, Wiz, OpenAI and Quarkslab disclosed two memory-safety bugs in the PHP runtime, together named “PHP2Shell”:
CVE-2026-109618: PHP can run out of memory before some internal data is initialized. During request cleanup it then treats that incomplete data as valid.CVE-2026-109619: a fatal error can leave PHP holding stale references. A later request handled by the same worker process may follow them into freed memory.
An attacker can trigger both bugs remotely with specially crafted HTTP requests. The consequences range from denial of service and leaks of sensitive data to full remote code execution on the web server. The flaw is in the runtime itself, so updating a site's code or plugins does not fix it. Platforms such as WordPress and Magento are potentially exposed. Details leaked before the coordinated release date, and real attack traffic, including attempts to evade WAF rules, appeared within hours.
PHP has published a security release, and Cloudflare has shipped WAF rules for all plans. The only real fix is to upgrade PHP on every affected server. (Source: Cloudflare blog.)
Afi impact: none. The Afi platform contains no PHP code. Our backend services, APIs and agents are written in Go, a memory-safe, compiled language, and ship as minimal container images. No PHP runtime is installed anywhere for an attacker to target.
eMudhra / emSign certificate authority key compromise
eMudhra, the Indian certificate authority that operates the emSign brand, was found to have eight intermediate CA certificates with weak, derivable private keys. Browsers, operating systems and many applications trusted these intermediates. Anyone who derived the keys could therefore issue a valid-looking certificate for any domain, then impersonate websites and intercept or tamper with encrypted traffic.
This was not a weakness in TLS encryption itself. It was a failure in the authentication layer: the certificate system that tells your browser which server it is really talking to. Browser vendors pushed emergency distrust updates (for example via Chrome CRLSets). Platforms such as Cloudflare released patched clients and rolled out server-side mitigations within about a day. (Source: Cloudflare blog.)
Afi impact: none. Afi has never used eMudhra or emSign certificates. All of our public endpoints use certificates from Let's Encrypt. Their certificates are short-lived and issued automatically through the ACME protocol, so we never have to emergency-replace long-lived certificates, and every certificate is logged publicly in Certificate Transparency.
How Afi protects your data in transit
Avoiding these two specific problems is only part of the story. Our transport security is designed to limit the damage from the next incident too:
Let's Encrypt certificates
Short-lived certificates, issued and renewed automatically via ACME and logged in public Certificate Transparency. Rotation is routine, never an emergency.
Hardened TLS 1.3
TLS 1.3 is our default, with forward secrecy and only modern AEAD ciphers. TLS 1.2 is allowed only for legacy clients, with a strict cipher list. Older protocols are disabled.
Preparing for post-quantum
We are preparing our TLS stack for post-quantum key exchange (hybrid ML-KEM). The goal is to protect today's traffic from future “harvest now, decrypt later” attacks.
Memory-safe stack, no PHP
Our services are written in Go and deployed as minimal containers. That rules out whole classes of memory-corruption bugs like PHP2Shell.
At a glance
| Incident | Affected technology | Used by Afi? | Customer action |
|---|---|---|---|
| PHP2Shell (CVE-2026-109618 / -109619) | PHP 5.4+ runtime | No | None required |
| eMudhra / emSign key compromise | eMudhra intermediate CAs | No | None required |
A general recommendation
Afi is not affected, but these incidents can still affect your own environment. We recommend that you:
- Patch PHP on every server you run (or ask your hosting provider to), even if a WAF sits in front of it.
- Keep browsers, operating systems and container images up to date so the eMudhra distrust actually reaches every client, including trust stores bundled inside applications and SDKs.
- Do not silence certificate errors by turning off verification. An unexpected certificate warning is exactly the signal these attacks try to hide.
Security is a core part of a backup platform, not an add-on. If you have questions about this post or about Afi's security architecture, contact our team at security@afi.ai.