Author: Andrew Mikhaliuk, CEO of CoreWin
Hello to all IT and cybersecurity enthusiasts and professionals. Today I want to share something interesting and, at first glance, seemingly insignificant — a vulnerability. Yes, indeed, this has already become a very trivial routine: yet another vulnerability, of which more than 110 appear on average per day, should not, in theory, be extraordinary news. Of course, we monitor vulnerabilities and respond to the most dangerous ones — how could it be otherwise? This is important, no doubt, but it has turned into everyday routine.
So, I also began my Monday morning with coffee and reviewing reports on newly discovered vulnerabilities, paying attention first and foremost to those labeled critical. And I came across a critical Use-After-Free vulnerability in Google Chrome (immediately interesting, since it is undoubtedly the most widely used browser).
A Brief Overview of Use-After-Free Vulnerabilities
Use-After-Free (UAF) is a type of programming error that occurs when a program continues to use a block of memory after it has already been “freed.”
Why is Use-After-Free a Critical Vulnerability?
Imagine that random-access memory is like a set of numbered rooms in a hotel:
- A program books a room and places its data there.
- When the data is no longer needed, the program frees the room, signaling to the system that the resource can be handed over to another client.
- If, after this, the program continues to access the already freed room, a Use-After-Free situation occurs.
And now, pay attention to how attackers turn this bug into a weapon:
- Since the OS memory system reuses freed areas, an attacker, through a specially crafted request, creates a new object in the same location. Now, instead of legitimate data, the memory contains data controlled by the attacker.
- The vulnerable process mistakenly refers again to the object that was considered already deleted. It reads or executes code from the memory block, the contents of which are now controlled by the attacker.
- From there, many options arise. If the memory contained a function pointer, the attacker replaces it with the address of their malicious code — leading to arbitrary code execution. If it was an object with access rights, the attacker can escalate the process’s privileges. If it was a data buffer, the attacker can extract information from another user or process.
- Depending on the context, the attacker can achieve: remote code execution in the browser (for example, in Chrome or Edge); interception of sensitive data from memory; control over a system service with elevated privileges.
The Vulnerability in the ANGLE Library
Phew… theory is done! As you already understand, Google Chrome could execute a piece of code from a website it was processing if that site contained a crafted attack, specifically due to Google’s open-source ANGLE library. In browsers (such as Google Chrome and Microsoft Edge), ANGLE is used to render WebGL graphics. Thanks to it, web applications that use 3D graphics can run on Windows, Linux, macOS, and other operating systems without code changes. That means playing a visual novel on itch.io or visiting a website with fancy spinning graphics could, in the background, trigger a process on your PC that pulled in a worm and infected the system (for example).
Attention! The Most Interesting Part! This Vulnerability Was Found by AI
On August 11, 2025, Big Sleep identified a Use-After-Free vulnerability in the ANGLE component. Big Sleep is an automated AI-based researcher that combines dynamic analysis, fuzzing, and machine learning. Its task is to detect anomalies in memory usage. Google first reported this discovery in the Chrome Releases blog.
Do you understand what happened? AI independently discovered a critical CVE vulnerability in widely used software. Entirely on its own and automatically. I felt as if I were in a cyberpunk future, where singularity automated cybersecurity has been reached, where AI not only assists but replaces the manual work of researchers in discovering zero-days.
Until now, AI had been used only as an auxiliary tool. ML models were applied for bug prioritization, patch analysis, and fuzzing hints. But an independent discovery of a zero-day and assignment of a CVE had never been recorded before. This event is a historic precedent: for the first time, the CVE description names not a human but AI as the discoverer.
Conclusion
What can we do while such AI-based researchers are not yet commercialized and available for purchase? The answer is — choose solutions that are already preparing for an AI-driven future, i.e., cybersecurity companies that are AI-ready today. For example, Invicti Security recently introduced an updated product with a new AI-powered DAST engine, or Mend AI, which automates the detection and assessment of AI component risks, ensures prioritized vulnerability remediation, enforces security policies, strengthens system prompts, and performs red teaming of AI behavior specific to your applications.
