Oct 27, 2026 · @DUCTUS LEGAL

A warning India cannot treat as routine

India’s cyber agencies are racing to get two critical PHP flaws patched before attackers reach government and banking websites. CERT-In issued vulnerability note CIVN-2026-0510 on 21 October 2026, rated it CRITICAL, and said multiple reports confirm large-scale exploitation in the wild. Two days later it followed with advisory CIAD-2026-0052, aimed at MSMEs running PHP websites.

The push has reached the states. The National Informatics Centre’s Cyber and Information Security Group sent an advisory to all states, and Madhya Pradesh officials admitted that several state government websites were found vulnerable, though MP CERT reports no damage so far.

This matters because India runs its public life on the web. Aadhaar, the GST Portal, UPI and MCA21 form the core of our Digital Public Infrastructure (DPI). No public report says these core platforms run vulnerable PHP. But around each of them sits a wide ring of state portals, bank websites, payment front-ends, GST Suvidha Providers, KYC agents and vendor-built dashboards. Many of these are PHP applications built by contractors. An attacker does not need to breach Aadhaar itself if a poorly patched partner site holds the same citizen data.

What the PHP flaw actually is

PHP is the server-side language behind most of the web. By W3Techs’ count it runs about 69% of websites whose server language is known, including WordPress, Drupal, Joomla, Laravel and Magento sites. A flaw in PHP itself is therefore a flaw under millions of applications at once.

The bug pair, nicknamed PHP2Shell, consists of two vulnerabilities, each rated 9.2 out of 10 (CVSS v4.0) by the PHP security team:

  • CVE-2026-109618 (out-of-memory corruption). When a server runs out of memory while it is still setting up an incoming request, PHP’s clean-up routine can treat half-built data as valid. A crafted request can turn that confusion into code running on the server.
  • CVE-2026-109619 (stale global state). Data left over from one visitor’s request can point to memory that has already been freed. A later request handled by the same worker can then misuse it. This is a classic “use-after-free” bug, and it can also leak memory contents.

In plain terms: an attacker who has no password and no account can send one specially built web request and take control of the server. PHP says every installation that serves web requests is at risk, whether it runs PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed (Tenable FAQ).

The fixes shipped on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches (7.4 to 8.1) got only source backports, and anything older has no fix at all. Two details make this worse than an ordinary bug. Amazon’s threat team saw exploitation attempts on 17 October, four days before disclosure. And installing a patched package does nothing until every PHP worker is restarted, because the vulnerable code stays in memory.

There is also an AI angle. The researchers credited with finding the bugs, including Calif and Wiz, have said they used AI models in their research. AI is now finding deep flaws faster than organisations can patch them.

Consequences: what an attacker can do with one request

Remote code execution is the worst class of web vulnerability, because the attacker effectively becomes the server’s administrator. Once inside, they can:

  • Steal data at scale. Database passwords and API keys sit in server memory and configuration files. From there an attacker can export customer records, KYC documents, PAN and Aadhaar numbers, account balances or GST filings.
  • Plant web shells. A small hidden file gives the attacker a permanent back door that survives the patch. This is why agencies tell teams to hunt for new PHP files, not just update.
  • Tamper with transactions. Scripts injected into login or payment pages can skim credentials and OTPs, or redirect UPI collect requests.
  • Move inward. A public website is often a bridge into an internal network: core banking, HR systems, or a state’s citizen database.
  • Launch ransomware or defacement. Two earlier PHP flaws in the US CISA catalogue were used in ransomware campaigns.

For a bank, the cost is regulatory as well as financial. RBI’s IT governance directions and CERT-In’s 2022 directions, which require cyber incidents to be reported within six hours, both come into play. For a government department, the cost is public trust. India has seen this before: in 2018, Aadhaar details of millions leaked not from UIDAI’s core system but through state government websites that exposed data by mistake.

The lesson is that DPI is only as safe as its weakest connected website. The core may be hardened, but the edges are often a forgotten PHP portal built by a contractor in 2017 and never updated.

Why this is now an AI governance problem

PHP2Shell is a cyber security story, but it is equally an AI policy story. The way software is built in India has changed faster than the way it is checked.

Startups and many established organisations now rely heavily on “vibe coding”: describing what they want to an AI assistant and shipping whatever code comes back, often with little human review. The speed is real. The checks are often missing. In practice this produces three risks that PHP2Shell exposes clearly:

  1. Nobody knows what is running. AI tools readily generate a PHP login page, a payment form or a KYC upload flow, and pull in libraries and server settings along the way. If no one keeps an inventory, no one can answer the first question every advisory asks: which of our servers run PHP, and which version?
  2. Old patterns get copied. AI models learn from public code, much of it years old. They can suggest outdated PHP versions, insecure file-upload handling or default configurations that agencies have warned against for years.
  3. Accountability blurs. When a breach happens, “the AI wrote it” is not a defence. Under the DPDP Act, the Data Fiduciary is responsible for reasonable security safeguards, regardless of who or what wrote the code.

The same week, attackers and defenders both used AI. Researchers used AI to find PHP2Shell; attackers will use AI to weaponise it. An organisation that uses AI to write code, but not to review, test and monitor it, is fighting with one hand. AI governance therefore cannot stop at chatbot ethics and bias. It must cover how AI-generated code enters production: who approves it, how it is tested, and how it is patched.

What organisations must do now

Patching PHP2Shell is the immediate task. The larger task is building a regime where the next flaw does not catch organisations unprepared. That needs three layers working together.

1. Treat privacy law as a security mandate. The DPDP Act, 2023 requires Data Fiduciaries to take reasonable security safeguards to prevent personal data breaches, and the penalty for failing to do so can reach ₹250 crore. Organisations should not wait for May 2027 to act as if these duties apply. Practical steps: map where citizen and customer data lives, minimise what is collected, encrypt it at rest, and prepare breach-notification workflows for both the Data Protection Board and affected individuals.

2. Adopt a written AI governance policy for code. Every organisation using AI coding tools should be able to show:

  • an approved list of AI tools and where they may be used;
  • mandatory human review and security testing (static analysis, dependency scanning) before AI-generated code touches personal or financial data;
  • a software bill of materials (SBOM) for every application, so the PHP version and every library are known;
  • clear ownership: a named person accountable for each production system, not “the model”.

3. Make cyber audits strict, regular and independent. Annual checkbox audits are not enough. Regulators and boards should expect:

  • CERT-In empanelled audits for all internet-facing applications, including vendor-built ones;
  • patch timelines written into contracts, with critical flaws fixed within days, not quarters;
  • an end-of-life register, so systems on unsupported PHP (8.1 and older, and 8.2 after December 2026) are upgraded or retired;
  • incident drills that rehearse a midnight patch, an evidence capture and the six-hour CERT-In report.

For banks and fintechs, RBI and SEBI already demand much of this. The gap is largest among startups, state departments and small vendors, which is exactly where AI-assisted coding is growing fastest.

The missing referee: the Data Protection Board

Unfortunately, the institution meant to enforce all of this barely exists outside the gazette. A recent RTI disclosure indicates that no visible work has been done towards making the Data Protection Board of India (DPB) functional.

The official record points the same way. The Board was established by notification on 13 November 2025, when the DPDP Rules were notified. Yet MeitY invited applications for its Chairperson and four Members only on 6 May 2026, almost six months later. Replying to Lok Sabha Unstarred Question 3960 on 12 August 2026, the government described the selection process but reported no appointment. Trackers of official notifications found none as of 21 September 2026, and none as of mid-October.

This matters directly for PHP2Shell. Under the Act, a breach must be reported to the Board, and only the Board can inquire into it and impose penalties. Courts have already begun sending petitioners to the Board as the proper forum, even though it has no members to hear them, as a LiveLaw analysis noted. If a citizen’s data leaks today from an unpatched PHP portal, there is no functioning data protection regulator to complain to.

My view: expect the statutory deadlines to slip

The DPDP Rules set an 18-month transition from November 2025. Most Data Fiduciary obligations, including security safeguards, breach notification and data principal rights, are due to take effect around May 2027. Consent Manager registration opens in November 2026.

In my opinion, given the PHP2Shell crisis and the state of the Board, the government is likely to extend these statutory deadlines. The reasons are practical. Thousands of organisations, including state departments, are now spending their scarce security budgets on emergency patching rather than DPDP readiness. A regime whose enforcer has no members cannot credibly start penalising breaches on schedule. And industry will argue, with some force, that compliance cannot be demanded while the adjudicator is still being recruited.

An extension would be understandable, but it would be a mistake to read it as relief. Attackers do not observe compliance calendars. PHP2Shell shows that a single flaw can expose citizen and customer data within days. Organisations should use any extra time to do the work, not to postpone it: patch fast, inventory every system, govern AI-written code, and audit vendors strictly.

India has built world-class Digital Public Infrastructure. Protecting it now requires world-class discipline in how software is written, checked and maintained, and an independent Data Protection Board that actually sits.

–Dixit Mehta, Partner, Ductus Legal

Sources

Unknown's avatar

Published by DUCTUS EDGE-A KNOWLEDGE ATLIER

This blog is a medium adopted to exchange ideas and to draw attention to the modern laws, business laws, startup laws, miscellaneous legal and other issues and policies which have become omnipresent in our day to day life. We believes in, "An Idea can change your Life and echoes through your living."

Leave a Reply