On 26th October, Indian digital trust company eMudhra apologised for a security failure involving eight intermediate certificate authorities. A script error had produced weak private keys, including one with the numerical value of just four. The company announced an independent review and had already decided to leave the global SSL/TLS certificate business. chapter1mag.com
Most internet users do not know which company issued the digital certificate used by a website. When someone opens a bank’s website, their browser checks the certificate and the authorities behind it to help verify the identity of the connection. If an attacker can reproduce an authority’s signature, they may be able to create a fraudulent certificate that appears genuine.
CERT-In said the affected private keys had numerical values smaller than 256, making them easy to recover. The problem lay in how the keys were generated, rather than in the underlying cryptographic algorithm. An attacker would also need to intercept a user’s connection to use a fraudulent certificate for impersonation.
eMudhra said its investigation had found no compromise of infrastructure or customer data. It maintained that its digital signature, eSign and enterprise services operated on separate infrastructure and were unaffected. Browsers and other software blocked the affected certificates, while eMudhra began arranging replacements for customers.
Vinay Murarka, partner at V2Technosys, said the failure raised questions about how such weak keys were generated and passed through checks. He cautioned against dismissing the incident simply because browsers receive regular updates.
At roughly the same time, website operators faced an emergency involving PHP, software that processes requests behind many websites. Two vulnerabilities, collectively called PHP2Shell, could allow an attacker to make a vulnerable server run instructions without logging in.
The flaws could be triggered before a website’s own code and login checks came into play. Updating a website’s content management system alone would therefore not fix the underlying PHP installation. Website owners had to rely on their hosting providers or server administrators to apply the updates.
Amazon Threat Intelligence identified an exploitation attempt against its monitoring system on 17th October, four days before public disclosure. It remained unclear whether the early attempts would have succeeded against real-world systems. An attempted attack does not establish that every targeted website was compromised.
Vipul Sipani, founder of Business Upturn, described checking and patching servers to protect publication databases and other business information. He advised website owners to ask their providers whether their servers were protected. Firewalls could help block known requests, but did not replace PHP updates.
In Japan, GMO Internet suspended servers after finding unauthorised programs in some customer environments. Its remote Windows service was used for automated foreign exchange trading. The company identified 26,739 potentially affected servers, a figure that did not represent a confirmed count of infections. Customers were advised to change passwords, end active sessions and check their trading accounts.
Other incidents added to the workload for security teams. GitLab and Node.js issued updates, a malicious LiteLLM release reached software users, and Capcom reported unauthorised access affecting around 11.7 million account email records. Microsoft also documented attempts to access more than 2,250 Microsoft 365 business environments through compromised ConnectWise application access. That figure was not a count of confirmed data thefts.
AI has a role on both sides. Researchers can use it to examine code, test vulnerabilities and check fixes. Attackers can use it to study disclosed flaws and develop attacks more quickly. For users, the practical steps include keeping devices and browsers updated, paying attention to security warnings and being cautious of suspicious messages.
Website owners must check software versions, apply fixes, replace certificates where necessary and investigate possible earlier access. An update can close a vulnerability, but it cannot by itself show whether an attacker used it before the fix was installed.
Read the full article on Chapter One Magazine.
