On 26th October, Indian digital trust company eMudhra issued a direct apology over a security failure involving eight of its intermediate certificate authorities. “The flaw was ours,” the company said, acknowledging that a script error had resulted in weak private keys. It announced an independent review and promised an explanation of why its controls had failed to detect the problem.
eMudhra had already announced its decision to withdraw from the global SSL/TLS certificate business. The disclosure that prompted the response was extraordinary. The affected secret keys could be recovered almost instantly. According to security researcher Scott Helme, one of the keys was simply the number 4.
Before the incident, the company name ‘eMudhra’ would have meant little to most internet users. People recognise the bank, shopping platform or government portal they visit. They are unlikely to know which organisation issued the digital certificate their browser relies on to check that website’s identity.
A failure of this scale in the background system required action across browsers, operating systems and other software. India’s Computer Emergency Response Team, CERT-In, warned that the compromised keys could be used to issue fraudulent certificates and impersonate legitimate websites under the conditions described in its advisory. It also clarified that eMudhra’s Indian digital-signature and eSign services were unaffected.
On 21st October, the Ministry of Electronics and Information Technology, MeitY, announced that a special team had been constituted to investigate the incident. As reported by OpIndia, the ministry described the impact on Indian websites and applications as limited and brief. It clarified that the international certificate business operated under a global trust framework and independent audits, in which MeitY was not involved.
A security incident concerning eMudhra’s Public Key Infrastructure (PKI) was reported in the public domain. Meity has taken serious note of the reported incident. A special team has been constituted to investigate the matter.
— Ministry of Electronics & IT (@GoI_MeitY) October 21, 2026
Around the same time, website administrators were dealing with another emergency. Two critical flaws in PHP, software used to operate websites, prompted urgent updates. In Japan, a cloud-computing service suspended servers after discovering unauthorised programs. Other companies disclosed compromised accounts, exposed information and disruption to customer services.
The incidents involved different systems and different causes, with several disclosures and emergency responses coming in quick succession during October. They brought problems normally confined to technical teams closer to people using websites to shop, work, study and manage their money.
Consider someone opening their bank’s website. Before entering a password, they need assurance that their browser is communicating with the bank’s server, rather than an impostor.
Digital certificates help provide that assurance. A certificate authority issues a digitally signed certificate linking a website’s address to a cryptographic public key. The website’s server must demonstrate possession of the corresponding private key. The browser checks the certificate and the authorities behind it before accepting the connection.
A useful comparison is an identity document carrying an authorised issuer’s seal. The document’s value depends partly on whether that seal can be trusted. If someone can reproduce the issuer’s signature, they may be able to create documents that appear authentic.
A certificate does not guarantee that the business operating a website is honest. It helps establish the identity of the connection. Mozilla’s explanation of the eMudhra incident describes why a compromised signing key threatens that process. An attacker could issue certificates for websites they do not control.
Speaking to Chapter1, Vinay Murarka, partner at V2Technosys and a digital transformation strategist, used the example of a lock manufacturer’s master key to explain why the failure deserved attention.
The concern is that someone else can reproduce the proof that software has been taught to accept. Possession of an affected key does not automatically open every website or decrypt everyone’s previous browsing activity.
Mozilla specified the additional condition. According to Mozilla, an attacker able to intercept a user’s connection could use a fraudulent certificate to impersonate a website and potentially read or modify traffic while the affected certificate remained trusted.
The problem lay in the generation of the keys. CERT-In said the affected private keys had numerical values smaller than 256. They lacked the randomness needed to make them difficult to discover and could be recovered almost instantly from their corresponding public keys. The agency explicitly stated that this was a key-generation failure, rather than a weakness in the underlying P-384 cryptographic algorithm.
In ordinary language, the mathematical lock was not defeated after an extraordinary effort. The secret selected for it was far too easy to find. eMudhra traced the affected certificates to a key-generation exercise in April 2025. In its earlier statement, the company said the incident concerned specific intermediate authorities and did not compromise its root private keys. Intermediate authorities sit within the chain of trust and can issue certificates beneath them.
Murarka said the central question was how such insecure keys had been produced and allowed through the process in the first place. He added that the explanation would have to come from the company.
He also rejected the suggestion that the incident could be dismissed because browsers receive updates regularly. In his assessment, the frequency of routine updates does not make a failure in a trusted certificate authority insignificant.
The promised investigation will now have to address that concern. Announcing a review establishes what the company intends to examine; it does not yet explain why the failure escaped detection.
The seriousness of the weakness should not be confused with proof that customer information was stolen. In its 26th October update, eMudhra maintained that the affected intermediates had not issued publicly trusted end-user certificates and that its investigation had found no compromise of infrastructure or customer data.
It also said its digital-signature, eSign and enterprise services operated on separate infrastructure and were unaffected. These remain the company’s attributed findings. According to Murarka, no confirmed victim who had suffered a loss through the affected keys had surfaced at the time of the interview. However, this does not mean that no one was affected. His concern was the security failure and the protective action it required.
Cloudflare’s response shows why the issue extended beyond organisations purchasing certificates directly from eMudhra. In its incident account, Cloudflare described updates to shared certificate-trust systems, services and applications. It also released updates for products including its WARP client and cloudflared software. Its review had not identified active exploitation on Cloudflare services.
A business can therefore have work to do even if its own website does not display an eMudhra certificate. Software making connections to other services may depend on the affected trust chain.
For users, some protection arrived automatically. Mozilla said Firefox users with standard configurations received its certificate block without needing to restart or manually update the browser. Additional releases extended protection to other configurations and applications.
Google Chrome blocked the compromised eMudhra intermediate CA keys via a CRLSet update on October 17, 2026, within roughly 100 minutes of the report, protecting users immediately without any browser restart or update, and later pushed an equivalent block to Android through Google Play Services. It is also removing the parent emSign ECC Root CA – G3 from the Chrome Root Store so that other software relying on that store is protected, which will break any remaining legitimate certificates chaining to the root until site owners switch to a different trusted hierarchy.
eMudhra’s decision to leave the global SSL/TLS business creates a migration task for customers. The company says it is moving affected G3 customers, as well as its wider TLS customer base, to alternate certificates at no cost.
For a website operator, replacement is necessary to maintain a connection that browsers accept. If a certificate chain is no longer trusted and replacement is delayed, visitors may encounter a security warning.
Murarka said migration to other providers could limit disruption. He did not regard leaving the business as inherently wrong. In his view, withdrawing from an activity a company cannot manage adequately can be a sensible decision.
The withdrawal concerns a particular business segment. It should not be read as an announcement that all eMudhra services are closing. The failure, the company’s response and the arrangements for customers each require their own assessment.
While eMudhra’s problem involved website identity, PHP2Shell concerned what a website’s server could be made to do. PHP is a programming language used behind the scenes. When a reader opens an article, submits a form or logs into an account, PHP may process the request and retrieve the information required to display the page.
A visitor does not usually install it on their phone. It runs on the computer serving the website. This is why responsibility for fixing the vulnerability normally rests with the hosting provider or server administrator.
On 21st October, the PHP project released updates addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Its release announcements listed PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 among the fixed versions and urged immediate updating.
The flaws could allow unauthenticated remote code execution. Put simply, an attacker might make the server run instructions without first logging into the website.
A visitor should be able to send a shop an order. They should not be able to turn that request into an instruction telling the shop’s computer to hand over files or execute another program.
The flaws arise in PHP’s handling of memory and information associated with incoming requests. One involves an error when PHP runs out of memory. Another involves internal information remaining available beyond the lifetime of the request it belongs to. Carefully constructed requests can turn those conditions into opportunities to execute code.
The important point is where this happens. The Imunify360 advisory explains that affected processing can occur before the website’s own code runs. Protection built into a login form therefore does not remove a vulnerability in the software processing the request.
Murarka said the required update was to the PHP installation on the server. Updating the website’s content-management system alone would not replace that underlying software.
This applies to small websites on shared hosting too. A person running a blog or local business website may never manage the server directly. They still need the hosting company to confirm that the relevant fix has been deployed.
The possible damage depends on the permissions available to the compromised process and the information it can reach. It should not automatically be described as complete administrative control over the machine.
However, website files may contain credentials used to connect to databases or other services. Access to those files can create further opportunities.
The risk was not confined to researchers demonstrating what might happen. Amazon Threat Intelligence identified an exploitation attempt against its MadPot monitoring system dating to 17th October, four days before public disclosure.
It subsequently observed attempts from additional infrastructure and said that, after the release, public exploit code was used against its sensors almost immediately.
Technical analysis was continuing, and it was unclear whether the early attempts would have succeeded against real-world systems. Attempts observed by security sensors do not establish that every targeted website was successfully compromised.
For administrators, the timeline means that checking for suspicious activity matters alongside patching. Installing a fix closes a vulnerability; it does not establish whether someone used it earlier.
Vipul Sipani, founder of Business Upturn, described the problem from the perspective of someone managing websites and servers. Sipani said he had spent the preceding days checking and patching systems. His concern was the potential loss of material needed to operate a publication, including its articles, database and other business information.
For a publication, a database can contain years of reporting. For a small shop, it may hold orders and customer records. Restoring a service involves more than making its homepage visible again.
His practical advice was for website owners to ask their provider whether their server was protected against both vulnerabilities.
Sipani’s account also referred to firewall protection. Such protection can help, but it is not a substitute for updating. Imunify360’s own advisory says its rules block known attack requests while identifying routes they do not fully cover. Its recommendation remains to update PHP on every server.
The PHP team issued another warning on 23rd October. An additional issue, CVE-2026-115560, could arise under an unusual combination of settings and application behaviour involving session handling. Its official notice advised affected configurations to disable session upload progress while a fix was being prepared for the regular release cycle.
That additional issue has narrower conditions than the original two flaws. It does not mean every updated installation remains exposed in the same way. It does mean administrators must read subsequent guidance rather than treat the first update as the end of the incident.
GMO Internet’s Onamae.com Desktop Cloud incident shows how a compromised cloud service can create consequences beyond an unavailable website.
The service provides remote Windows computing environments used for automated foreign-exchange trading. Customers can leave trading software running on a computer hosted by the provider, rather than keep their own computer operating continuously.
GMO’s initial notice confirmed unauthorised access and the installation of unauthorised programs in some customer environments. It identified 26,739 servers as potentially affected and began suspending servers on 21st October. That figure describes potentially affected servers, rather than a confirmed count of infected computers, websites or individual customers.
The company’s subsequent notices addressed trading-account security. Its 24th October customer warning urged users to change relevant passwords, end existing sessions, check balances and trading histories, and enable two-factor authentication where available. It also warned against responding to messages from anyone claiming to be the attacker.
Changing a password and ending an existing session are separate actions. A password change may prevent a fresh login, while a session already established may require separate termination.
GMO also announced a process to compensate realised losses from unauthorised trades that its investigation established were caused by this incident. Its fourth notice excluded ordinary market losses, expected profits and other indirect damage from that undertaking. It disclosed monetary demands from the suspected attacker and said it would not comply.
A remote computer used for trading may hold access to another financial service. If those credentials become available to an intruder, protecting the customer requires action beyond switching off the compromised computer.
PHP was not the only widely used software receiving urgent attention. On 21st October, GitLab released fixes for a maximum-severity vulnerability in its regular-expression compiler. Regular expressions are patterns software uses to find or match text.
GitLab said a specially crafted expression could, under certain conditions, allow an unauthenticated person to execute code on a vulnerable server. Its advisory identified the issue as CVE-2026-110264 and rated it 10.0.
GitLab helps organisations store source code and manage development work. Access to such a platform can be sensitive for reasons extending beyond the contents of a public webpage.
The company said GitLab.com was already patched. Organisations operating their own affected installations needed to update. A flaw in a product does not mean every customer uses the same vulnerable version or deployment.
Node.js, another platform used to run applications and online services, also issued security releases on 21st October. These addressed ten listed issues, including a flaw in Brotli decompression that could permit remote code execution, alongside problems involving DNS and certificate hostname checks.
Compression makes information smaller for storage or transmission. Decompression restores it. A flaw in that unpacking process can make the software handling externally supplied data unsafe.
Neither announcement, by itself, establishes that every affected organisation was attacked. Both created another set of fixes for technical teams to assess and deploy.
A separate investigation concerned HTTP/3, one of the systems browsers and servers use to exchange information. In research published on 20th October, FoxIO described weaknesses in how several implementations handled compressed request headers. These carry information accompanying a request. In affected implementations, a relatively small input could expand into a much larger amount of information in memory.
FoxIO found seven of the ten implementations it tested vulnerable. Some had fixes available, while others remained unpatched at disclosure. The original research described the risk of resource exhaustion.
Think of a service counter where one short request forces staff to produce thousands of documents. The request itself is small, but the work it triggers can overwhelm the counter.
For a website, that can mean becoming slow or unavailable. It is different from stealing a database, but users can still lose access to a service.
Oracle’s 20th October security update added to the maintenance burden, listing 1,295 new security patches across its product families. That describes patches, rather than 1,295 breached organisations or necessarily 1,295 unique vulnerabilities.
The ConnectWise incident showed how access granted to an external provider can become a route into other organisations.
Backup services need permission to work with business information. Customers grant that access for a legitimate purpose. If an attacker compromises the application identity used by the service, the existing permissions can become useful to the intruder.
In its 21st October investigation, Microsoft assessed that Storm-0940, a group it associates with Chinese state interests, was responsible for the ConnectWise supply-chain compromise. It documented attempts to access more than 2,250 Microsoft 365 tenants using compromised application access.
That number does not represent 2,250 confirmed cases of stolen customer information. Microsoft distinguished attempted authentication, successful access and subsequent activity.
It also warned that attackers could create additional credentials or change permissions inside affected environments. Disabling the original connection might leave other unauthorised access behind.
For a business, changing the lock used by a supplier is insufficient if an intruder has already created another way in.
LiteLLM’s investigation provided another example of how a mistake can remain useful to an attacker long after someone notices it.
The company’s 23rd October report said a configuration file published in May accidentally contained a master key for its Agent Platform. The exposed material was removed, but the master key was not revoked. An attacker later used it to gain access and acquire further credentials. The chain ended with the publication of compromised LiteLLM version 1.107.0 on 21st October.
Deleting a secret from a public page does not make a copied version stop working. The secret itself must be invalidated and replaced.
In this case, the consequence reached software users who would normally expect an official release to come through the project’s authorised process. LiteLLM said its newer account superseded assumptions in earlier investigation updates that had proved incomplete or inaccurate.
Other disclosures involved identifiable personal information. On 22nd October, Capcom confirmed unauthorised access affecting 11,774,247 email-address records and associated information in its CAPCOM ID service. It reported additional profile information in 43 records and unauthorised password changes affecting 196 accounts. Credit-card information was not among the affected information.
Those details give readers a clearer picture than the phrase “millions hacked”. The main exposed dataset, the smaller profile-data subset and the accounts with changed passwords involved different consequences.
A registered email address can still be useful for phishing. A fraudulent message claiming to come from a gaming company may appear more plausible to someone who holds an account with it.
California’s Department of Education also announced notifications concerning a security incident at Educational Testing Service. The department’s official FAQ said ETS identified unauthorised activity on 25th September involving a file-transfer site used to exchange statewide assessment information. The notification announcement was dated 16th October.
This was an earlier intrusion disclosed to affected families during the reporting period. The notification date was not the date of the attack.
For supermarket customers, the consequences were more immediately visible. Ahold Delhaize said in its 19th October update that malicious activity had led it to take systems offline as a precaution. The measures affected websites and apps across most of its brands in Europe and the United States, although the impact differed by brand.
A customer may experience this as an unavailable shopping app or interrupted online service. They do not need to know the name of a compromised component to be affected.
The company initially disclosed the incident on 12th October. It said physical stores remained open. The protective shutdowns affected selected systems, rather than every shop’s operations.
AI played a role in the PHP investigation itself. Wiz said its researchers used AI tools to help discover vulnerabilities, develop test exploits, detect attacks and validate the fix. These are different stages of security work. Finding suspicious code is one task; establishing whether someone can use it to break into a system is another. Wiz’s original research described AI assistance across that process.
The PHP Foundation’s account shows why that work matters. Warning signs behind one of the vulnerabilities had emerged during security work in 2024. A possible attack was considered, but researchers had not identified a concrete way to carry it out. Proposed fixes also raised concerns about compatibility and other problems they might introduce. The weakness existed before the latest AI-assisted investigation.
For a simple comparison, imagine an inspector finding a suspicious crack in a building. They still need to establish how deep it goes, whether it can cause a collapse and how to repair it without damaging something else. AI can help researchers examine the software equivalent of that crack, test possibilities and check proposed repairs.
The same assistance can be useful to attackers. Once a vulnerability becomes public, its description and the changes made to fix it can provide clues about where the weakness lies. Amazon Threat Intelligence warned that AI-assisted analysis makes it cheaper to turn those clues into a working exploit, allowing more attackers to act within hours or even minutes of disclosure.
Academic research has demonstrated this possibility under controlled conditions. In a 2024 study, researchers tested an AI agent against 15 known vulnerabilities. Given the published vulnerability descriptions, their GPT-4-based agent successfully exploited 87 per cent of the selected cases. Without those descriptions, its success rate fell to 7 per cent. The small experimental dataset does not mean AI can hack 87 per cent of websites. It shows how information about an already identified weakness can substantially improve an agent’s performance.
There is also evidence from actual malicious activity. Microsoft reported that Storm-0940 used the AI-based ARTEX framework to accelerate reconnaissance, password attacks and abuse of compromised application access. In several observed cases, the interval between initial targeting and privileged access was less than three hours. Microsoft also said most targeting was unsuccessful.
This does not mean AI is behind everything going wrong with the internet nowadays. AI can help defenders uncover and repair weaknesses, while helping attackers test and exploit them faster. Website owners may consequently have less time between receiving a security warning and facing attempts against their systems.
The responsibilities differ according to who controls the system. An ordinary visitor can keep browsers and devices supported and updated, take certificate warnings seriously and remain cautious about messages exploiting a publicised breach. They cannot repair a certificate authority’s key-generation process or install a fix on a supermarket’s server.
Website owners have more direct questions to ask. Which software versions are running? Has the provider applied the relevant fixes? Does a certificate need replacing? Has the organisation checked for unauthorised access, rather than assuming an update reverses an earlier intrusion?
Murarka’s emphasis was on treating the underlying failure seriously, even when the known customer base is limited or protective action has been swift. Sipani’s experience described the work that follows an alert: identifying exposed systems, arranging updates and considering what information could be lost.
The subsequent disclosures show how that work continues. eMudhra has promised an independent review and a root-cause account. PHP administrators have received further guidance. GMO’s response now includes trading-account protection and a compensation process.
For the person on the other side of the screen, these systems support ordinary daily tasks. They enter a password, submit a form or place an order expecting the organisations behind the service to protect the transaction. Meeting that expectation requires more than issuing the first warning. It requires fixing the failure, checking its consequences and explaining what remains unresolved.
That vast unknown frontier that has forever beckoned humanity is no longer beyond the edge of maps. It’s right behind our skulls. The mind is the last wild frontier left on Earth. It has no coastline, no flag, and until recently, no machine could even touch it.
Elon Musk claims domestic “oligarchs” like Mukesh Ambani are intentionally blocking Starlink’s entry into India. We fact-check his latest social media meltdown against regulatory realities, the myth of an unconnected India, exorbitant data pricing, and the American protectionist hypocrisy driving this narrative.
Indian investigations now combine device data with WhatsApp chats, CCTV, CDRs, metadata, witness accounts and records held by technology companies, but each source has limits and must be interpreted before responsibility can be attributed reliably.
Selected issues, clear explanations and thoughtful perspectives—delivered when we publish.
