PITY THE cyber-defenders. Occasionally, the industry must burst into action following the unheralded revelation of a vulnerability in some widely used software. Rarely, however, must they do so several times in the same week.

On October 20th the security teams at major web browsers received an unusual email. It read “we have a problem here” and was accompanied by a file containing eight private security keys: randomly generated numbers used to encrypt communications across the entire internet. Such keys should be 116 digits long to ensure security. Those in the email, originally issued by an Indian authority, were no longer than three. One was a private key of just “4”. To top things off, the email was signed simply “Wayne”.

Revoking such keys from important central databases is manageable. Checking every system has updated accordingly is hard work. Major web browsers keep their blacklists up-to-date, but many internet-connected systems do not adjust so easily. Some, like many Linux systems, require an active software update; others, like some command-line tools on MacOS, must be manually fixed.

Defenders were busily plugging those gaps when, on the morning of October 21st, another problem arrived. A pair of vulnerabilities had been exposed in PHP, a venerable programming language which underpins tens of millions of web applications, including message boards, financial portals and government websites. A patch was promised for the same afternoon. In the meantime, affected organisations were advised by governments to take their systems offline entirely—an instruction not issued lightly. Several government websites in Europe went dark.

The advice proved to have been reasonable. Hours after news of the vulnerability broke, and with over 12 hours before a patch was due, its details leaked. The vulnerability was as bad as it gets: a recipe for unauthorised remote code execution (RCE), letting an attacker take control of machines running PHP. Exploiting the vulnerability, as demonstrated by at least one widely shared proof-of-concept, was simple.

There is no direct link between the two weaknesses, but one strong relationship: both vulnerabilities seem to have been discovered by AI. The PHP vulnerability was found independently by two members of an AI cyber-defence consortium led by OpenAI, an American firm. The dodgy security keys were “possibly” found using AI too, according to eMudhra, the Indian company which issued them. Certainly, the method of disclosure suggests an unusual approach to research.

By October 22nd two further vulnerabilities had been published. GitLab, a software development tool, announced a patch for a weakness affecting 12 years of releases that could allow its own RCE, ranking it ten on a ten-point severity scale. Oracle, a data firm, fixed a similar weakness in Java, its widely used programming language, and ranked the severity 9.1. AI was probably used to uncover these flaws, too.

The episodes illustrate an uncomfortable reality of AI-powered cyber-security: fixing an issue sets a timer for its exploitation. The PHP bug was announced with 18 hours notice before a patch was released, in an effort to prepare defenders to install the update with alacrity. But an accidental release of a video demonstrating the vulnerability allowed others, ai in hand, to reverse-engineer the problem and work out how to exploit it. Shortly after, a security company published its version of the fix six hours early, allowing any attacker to examine exactly what was fixed, and therefore uncover more details of the weakness in unpatched systems.

Defenders once faced the difficult problem of finding the flaws in their own software before attackers did. Now they have a different challenge: with AI exposing a plethora of weaknesses, how can they spread news of the fixes to their users, without tipping off their enemies in the process?