Monday, August 17, 2026 Trend Press · Cloudflare Pages

The Trend Tribune

"All the trends that are fit to read" Morning Edition Free of Charge
TODAY'S LEAD STORY

"20 prompts, less than 24 hours"—a turning point into an era where anyone can build state-level offensive weapons.

This presentation examines the acceleration of AI-driven vulnerability discovery through the "Zoomsday" vulnerability disclosed by Israeli company A Security. It explains the zero-click vulnerability (CVE-2026-53413/53414/53415) in Zoom's annotation function, how a state-sponsored, weapon-grade exploit was completed in less than 20 prompts and less than 24 hours, a demonstration of silent device hijacking on macOS, the impact on all platforms including Windows, macOS, Linux, Android, and iOS, and the subsequent coordinated disclosure and fix.

"20 prompts, less than 24 hours"—a turning point into an era where anyone can build state-level offensive weapons.
(Photo: illustrative)

"20 Prompts, Less Than 24 Hours"—A Turning Point to an Era Where Anyone Can Create State-Level Weapons

In early August, Israeli security firm A Security disclosed a serious vulnerability in Zoom, which they named "Zoomsday." This vulnerability allows one participant to take over another participant's device during a video conference without requiring a single click. Beyond its technical severity, what was most shocking to engineers was the fact that it took fewer than 20 prompts to the AI ​​model and less than 24 hours to discover this vulnerability and actually build exploitable code.

A Flaw Lurking in the "Annotation Feature"

Zoomsday was a memory corruption vulnerability in Zoom's "annotation" feature—the function that allows users to write text and place shapes on the screen during a meeting. Because this feature runs constantly in the background, regardless of whether participants actually use annotations, it was a particularly dangerous "zero-click" vulnerability, meaning an attack could be completed without any action from the victim.

Zoom exchanges on-screen annotations not as simple images, but as structured data. The bug discovered lies within this completely proprietary protocol, a "black box" with no publicly available documentation. It's a combination of multiple vulnerabilities, registered as CVE-2026-53413, 53414, and 53415. The first, a buffer overflow (a classic but still dangerous vulnerability where data is written beyond the memory area), received a severity score of 8.3 out of 10, indicating a "high" severity.

From "6 Months, 5-Person Team" to "1 Day, 1 Person"

What shocked the industry wasn't so much the severity of the vulnerability itself, but the speed at which it was discovered. Omer Guru, CEO of A Security, told WIRED, "What used to take a team of five people six months can now be achieved in fewer than 20 prompts."

The company described this discovery as a "national-level, weapon-grade" vulnerability. Traditionally, the ability to discover this type of vulnerability and develop a working exploit (actual attack code that takes advantage of the vulnerability) was a domain only attainable by national agencies with ample budgets and specialized teams. Now, however, using publicly available AI models, a single researcher can replicate the attack in less than a day. A Security stated in a press release, "The barriers that previously kept this type of weapon rare have crumbled, and there will never be a return."

"Silent Hijacking" Demonstrated on macOS

A Security researchers also demonstrated the vulnerability on macOS to show how difficult it is to detect. They successfully launched the Safari browser without any visual indication appearing on the victim's screen. The attack has been confirmed on all major platforms supported by Zoom: Windows, macOS, Linux, Android, and iOS.

Zoom has approximately 220 million monthly active users and holds a 56% share of the video conferencing market. The sheer scale of the targets that could be attacked speaks volumes about the seriousness of this vulnerability.

Speed ​​of Response is "At Least a Consolation"

Fortunately, while the speed of the "discovery to exploitation" phase has garnered attention, the "discovery to reporting and fixation" phase followed a responsible disclosure process. A Security followed a "cooperative disclosure" procedure, notifying Zoom before publicly disclosing the vulnerability, and Zoom applied the fix in versions 7.0.6 and 7.1.5 (fast track version) before the public release.

However, Zoom has not officially clarified whether there was any evidence of exploitation of this vulnerability before the fix. This also means that users have no way of determining whether any third parties knew about the vulnerability before the fix.

What Engineers Should Consider

This news is two sides of the same coin as the OpenAI "Defender's Cybersecurity Model" we discussed recently. While there is a growing movement to provide powerful AI tools to the defense side, this case clearly demonstrates that attackers (in this case, researchers with ethical intentions) can also benefit from the same AI advancements at the same speed.

The fact that the cost of "finding vulnerabilities and making them exploitable" has decreased so dramatically is not something that all engineers involved in software development can ignore. Proprietary protocols of products and code paths that were previously optimistically assumed to be "too complex for attackers to find" can no longer be protected by the same logic. It may be time to rethink security review and penetration testing processes to accommodate the accelerated vulnerability discovery capabilities of AI.

サイバーセキュリティZoom脆弱性AI/MLエクスプロイト

"Making weak AI read the minds of strong AI"—The method of stealing inference traces across three major AI companies.

A joint research project by ELLIS Institute Tübingen, Max Planck Institute, MATS Research, and Snyk, titled "Stealing Reasoning Traces from Proprietary LLM APIs," discovered a vulnerability in OpenAI, Anthropic, and Google's cryptographic inference objects that allowed for compatibility across session, user, and model levels. The report explains the "decryption jailbreak" method, which involves injecting the cryptographic traces of a strong model into a weaker sibling model to decrypt them in plaintext, demonstrating the decryption of 315,320 blocks from 6,708 logs and the recovery of 182 sets of authentication information, and the varying levels of response from each company.

"Making Weak AI Read the Minds of Strong AI"—A Method of Stealing Reasoning Traces Across Three Major AI Companies

A paper reporting an intriguing architectural flaw common to the AI ​​reasoning APIs of three companies—OpenAI, Anthropic, and Google—is generating buzz in the research community. Titled "Stealing Reasoning Traces from Proprietary LLM APIs," this research is a joint effort by the ELLIS Institute Tübingen, Max Planck Institute, MATS Research, and the security firm Snyk. As a journalist with an AI research background, I want to examine the technical mechanisms of this research and its implications.

The Mechanism of "Encrypted Thought"

In recent years, major AI providers such as OpenAI, Anthropic, and Google have adopted a mechanism to deliver the internal "thought process" (chain-of-thought, the step-by-step reasoning process a model performs before arriving at a final answer) via APIs, rather than showing it to users in raw text, in the form of encrypted "reasoning objects." This was a measure to prevent the leakage of information that should be protected as intellectual property—the model's internal inference process—while simultaneously ensuring that the model could maintain context across multiple API calls.

This encrypted object cannot be intentionally read by developers, but by "replaying" it in subsequent API calls, the model can continue to respond based on previous inferences.

Discovered Flaw: The "Reusability" Problem

The research team discovered that this encrypted inference object had "compatibility" over a much wider range than anticipated. According to the paper's abstract, within each provider's ecosystem, encrypted blocks were completely compatible and interchangeable across sessions, users, and models.

In other words, an encrypted inference object generated in one user's session could be "injected" into a completely different session or even a different user account. Furthermore, if this was loaded into a less capable, less secure "sibling model" within the same provider, that model would simply write the encrypted content in plain text. The research team has named this method "decryption jailbreak."

"Claude Haiku 4.5" Exposes "Claude Opus 4.8's Thinking"

The concrete example provided by the research team is easy to understand. When an encrypted inference trace generated by a powerful model (e.g., Claude Opus 4.8) is injected into a weaker model within the same provider (e.g., Claude Haiku 4.5), this weaker model verbatim copies the inference content of the powerful model. There is absolutely no need to directly jailbreak (circumvent security mechanisms) the powerful model itself. Similar methods have been reported to work with OpenAI and Google Gemini.

This is an interesting example that demonstrates the limitations of evaluating the "security" of an AI model solely on the robustness of the model itself. No matter how robustly a powerful model implements security mechanisms, if another model with weaker security measures from the same provider is used as a "decryption tool," the model's inherent defenses become meaningless. ## 182 Credentials Actually Stolen

To demonstrate that this vulnerability is not merely a theoretical concern, the research team also conducted actual verification. They collected 6,708 agent execution logs publicly available on GitHub and Hugging Face, and decoded 315,320 inference blocks from them. In the process, they reported being able to recover 182 credentials, including API keys, passwords, and access tokens, from actual user sessions.

The paper further outlines four ways this technique could be exploited: stealing proprietary inferences for model distillation, extracting sensitive data from execution logs published by other users, recovering malicious content hidden behind seemingly secure answers, and concealing prompt injection (an attack that injects malicious instructions) within opaque inference blocks.

Differences in Responses from Each Company

Following this disclosure, there are differences in the responses of the three companies. OpenAI continues to recommend that developers manually manage stateless history and replay encrypted inference items. Google explains that it manages the compatibility of thought processes when a session switches models on the backend. Anthropic, on the other hand, has newly stated, following this disclosure, that thought blocks are tied to the model that generated them, and other models ignore them; therefore, they should be removed when switching models.

Neither company has made an official statement regarding the existence of this vulnerability, and it is not publicly linked whether the current documentation has been updated based on these research findings. According to the research team, the demonstrated attack vector ceased to function after the disclosing companies implemented countermeasures.

What Researchers Should Consider

The lesson this research teaches is that when evaluating the security of AI models, it is necessary to look not only at the robustness of a single model, but also at the design of the entire "ecosystem" to which the model belongs. Even a seemingly robust mechanism like encryption can be easily rendered ineffective if its operational design—in this case, the design where encryption keys were shared across sessions, users, and models—is flawed.

Going forward, it remains to be seen what technical countermeasures AI companies will implement against this type of architectural vulnerability, and whether similar vulnerabilities exist in other providers or model families that have not yet been discovered. Continuous verification by the research community will likely continue to play a crucial role in raising the overall security level in this field.

AI安全性LLMサイバーセキュリティ推論AI/ML

The concept of "robots with skin"—Generative Bionics' gamble on open-source survival strategy

On August 4th, startup Generative Bionics announced its smart-skinned humanoid robot, "Gene.01," as an open-source robot model. This article will examine its design philosophy of detecting contact across the entire surface of the robot, the rationale behind its open-source strategy as a latecomer, a technical comparison with Tacta Systems' haptic hands, a shared concern with NVIDIA's numerical approach to "collaboration without safety fences," and the verification challenges, including the fact that specific sensitivity and response speed have not yet been disclosed.

The Concept of a "Robot with Skin"—Generative Bionics' Survival Strategy: Open Source

On August 4th, the startup Generative Bionics announced its humanoid robot platform, "Gene.01." It boasts two key features: a design based on safe collaboration with humans, which the company calls "Smart Skin," and an open-source robot model. While there aren't any flashy funding figures, it's packed with intriguing technical choices for software developers, so let's delve deeper.

The Concept of Giving "Skin" a Sense of Touch

The "Smart Skin" concept that characterizes Gene.01 is a design philosophy that incorporates touch-detecting sensors into the robot's exterior itself. While Tacta Systems, which we previously covered, concentrated touch sensors in a specific part, the "hand," Generative Bionics appears to be aiming for a system that can detect external contact over a wider area—closer to the robot's entire "skin."

The aim of this design is to improve safety when working with humans. Conventional robots that rely solely on visual sensors such as cameras have the weakness of being unable to detect contact from positions outside their field of vision or unexpected collisions. If the robot's surface itself can directly sense "being touched," it could potentially improve safety in close-range work with humans by covering the blind spots of visual sensors.

Why "Open Source" Was Chosen?

Another distinctive feature is the choice to release the robot model as open source. Many of the humanoid companies we've looked at so far have adopted a strategy of keeping their proprietary control algorithms and AI models as trade secrets. Generative Bionics' deliberate choice to go against this can be seen as a strategic decision for a latecomer.

It's not realistic for a startup to directly compete with companies like Unitree, Figure AI, and Tesla Optimus, which already have mass production capabilities and massive funding, in terms of hardware manufacturing capabilities and financial resources. Instead, by involving the development community and incorporating improvements and application examples from external developers, they are accelerating the pace of technological evolution even with limited resources—a strategy similar to the path taken by Linux and Android in the software industry. It will be an interesting experiment to see how far this type of open-source strategy can take them in the field of robotics hardware design, which is usually a closed-source area.

A Grounded Appeal: "Safe Collaboration"

Gene.01's emphasis on "safe collaboration with humans" represents a slightly different direction from the grand vision of "fully autonomous, all-purpose robots" touted by many of the humanoid companies we've covered so far. Rather, it's a more concrete and grounded challenge: how to overcome the constraint of existing industrial robots being limited to "operating only within safety fences."

This is a similar concern to NVIDIA's efforts to numerically demonstrate "working with humans without safety fences," which we discussed previously. For humanoid robots to truly become widespread in factories and warehouses, the ability to work safely alongside humans is a far more practical requirement than flashy full-body movement capabilities.

The Challenge of "Actual Sensitivity" to be Verifyed

However, when evaluating this type of "smart skin" concept, there are several points that need careful consideration. First, specific performance figures—such as the actual sensitivity with which it can detect contact, and the speed of its reaction from detection to safe shutdown—have not yet been revealed. While Tacta Systems' tactile sensor, previously discussed, boasted a wide pressure range of 250 to 700,000 Pascals, the detailed technical specifications of Gene.01 have not yet been fully disclosed at the time of this announcement.

There is always a gap between the persuasiveness of a concept and its completeness as an actual product. How much the open-source approach can accelerate this technical verification process will be a point to watch in the future.

Things to Note from a Software Perspective

Generative Bionics' approach can be described as an attempt to carve out a unique position not through competition in terms of funding or mass production scale, but through its "open source" development model and the specific challenge of "secure collaboration."

While the entire humanoid industry tends to focus on massive fundraising competition and the display of flashy, full-body motor skills, this approach, which focuses on "unassuming but practically important issues," has a certain significance. We will be closely watching how much of a developer community the open-source robot model will actually attract and what kind of improvements and application examples it will generate.

ヒューマノイドオープンソース触覚センサーフィジカルAI安全性
Advertisement300 × 250