An ACM survey of 763 computer science educators from 49 countries shows that 68 percent have already changed their exams because of AI, shifting toward oral exams, proctored tests, and project-based work. Teaching is moving from writing code to understanding it. But nearly half of respondents say they lack proven examples for integrating AI into their courses.

The article The AI coding tutor paradox grows as educators scramble to rethink how they test real skills appeared first on The Decoder.

Wo du uns folgen kannst: Facebook, Reddit, Google News, X, Threads

Introduction

Note: This advisory was originally published on April 7, 2026, to provide tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) related to ongoing cyber exploitation of internet-connected operational technology (OT) devices by Iranian-affiliated advanced persistent threat (APT) actors. The authoring agencies updated this advisory on July 22, 2026, to add new guidance on detecting malicious changes in reusable code modules leveraged within Rockwell Automation PLC programs. It also expands the manufacturer scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded/manufactured PLCs, emphasizing the importance of restricting direct internet access and providing best practice resources for secure deployment.

The Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Environmental Protection Agency (EPA), Department of Energy (DOE), United States Cyber Command – Cyber National Mission Force (CNMF), and Department of the Treasury (Treasury) (hereafter referred to as the “authoring agencies”) are urgently warning U.S. organizations of ongoing cyber exploitation of internet-connected OT devices—including PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs—across multiple U.S. critical infrastructure sectors. As a result of this activity, organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files¹ and the manipulation of data displayed on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays. In a few cases, this activity caused operational disruption and financial loss.

The authoring agencies assess a group of Iranian-affiliated APT actors is conducting this activity to cause disruptive effects within the United States. The group targeted devices spanning multiple U.S. critical infrastructure sectors, including Government Services and Facilities (to include local municipalities), Water and Wastewater Systems (WWS), and Energy Sectors. The authoring agencies previously reported on similar activity targeting PLCs by CyberAv3ngers (aka Shahid Kaveh Group)—a cyber threat actor affiliated with Iran’s Islamic Revolutionary Guard Corps (IRGC) Cyber Electronic Command (CEC).

Due to the widespread use of these PLCs, and the potential for additional targeting of other branded OT devices across critical infrastructure, the authoring agencies recommend U.S. organizations urgently review the TTPs and IOCs in this advisory for indications of current or historical activity on their networks, and apply the recommendations listed in the Mitigations section of this advisory to reduce the risk of compromise.

If owners and operators discover an affected internet-accessible device in their environment, additional technical measures may be necessary to evaluate the risk of compromise. Please engage your cyber incident response plans and contact the authoring agencies and applicable vendors through existing support channels available to customers and integrators (see Contact Information) to receive support, mitigation, and investigation assistance.

For more information on Iranian malicious cyber activity, see CISA’s Iran Threat Overview and Advisories webpage and the FBI’s Iran Threat and Iran Cyber Threat Overview webpages.

Download the PDF version of this report:

(New, July 22, 2026) For a downloadable copy of July 22, 2026 IOCs, see:

• AA26-097A STIX XML (XML, 29 KB)
• AA26-097A STIX JSON (JSON, 30 KB)

For a downloadable copy of historical April 7, 2026 IOCs, see:

Background Information

Similar Historical Activity Targeting Programmable Logic Controllers

During a similar campaign beginning in November 2023, the IRGC CEC-affiliated cyber threat actors known as "CyberAv3ngers” targeted U.S.-based PLCs and HMIs, causing disruptive effects. Private industry and open sources also refer to this group as Hydro Kitten, Storm-0784, APT Iran, Bauxite, Mr. Soul, Soldiers of Solomon, UNC5691, and the Shahid Kaveh Group. These attacks compromised at least 75 devices, targeting U.S.-based Unitronics PLC devices with an HMI used across multiple critical infrastructure sectors, including the WWS. APT actors developed and deployed custom ladder logic code to these devices, replacing the valid ladder logic with malicious code that continues to be observed to date.

For more information on this group’s activity, see the joint Cybersecurity Advisory IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities.

Ongoing Threat Actor Activity Against U.S.-Based Programmable Logic Controllers

The FBI observed Iranian-affiliated APT actors targeting internet-exposed PLCs with the intent to cause disruptions—including maliciously interacting with project files, and manipulating data displayed on HMI and SCADA displays—to U.S. critical infrastructure organizations. Iranian-affiliated APT targeting campaigns against U.S. critical infrastructure have recently escalated, likely in response to hostilities between Iran, and the United States and Israel.

(New, July 22, 2026) At one U.S. victim, the FBI observed the APT actors download a malicious project file to a targeted PLC using configuration software. Analysis indicated the project file retained ladder logic for downstream function but added logic that overrode specific instruction sets responsible for maintaining safe operating parameters in the victim’s environment.

Since at least March 2026, the authoring agencies identified (through engagements with victim organizations) an Iranian-affiliated APT group disrupted the function of PLCs. Organizations across several U.S. critical infrastructure sectors (including Government Services and Facilities, WWS, and Energy Sectors) deployed these PLCs within a wide variety of industrial automation processes. Some of the victims experienced operational disruption and financial loss.

Technical Details

Note: This advisory uses the MITRE ATT&CK^® Matrix for Enterprise framework, version 19. See the MITRE ATT&CK Tactics and Techniques section of this advisory for tables of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.

Initial Access

(Updated, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using several foreign-based IP addresses to access internet-facing PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other manufactured PLCs [T0883]. The actors used leased, third-party hosted infrastructure and manufacturers’ PLC programming software to connect to misconfigured victim PLCs. Inbound malicious traffic has been observed targeting PLC devices on the following ports: 44818, 2222, 102, and 502, as well as targeting modems on port 22. Targeted devices include:

• Rockwell Automation: CompactLogix and Micro850 PLCs
• Schneider Electric: BMX P34/Modicon M340 PLCs
• Siemens: S7-1200 series PLCs

Command and Control

(Updated, July 22, 2026) The targeting of ports [T0885] associated with other OT vendors’ protocols suggests these actors are opportunistically targeting devices manufactured by companies other than Rockwell Automation/Allen-Bradley, including Schneider Electric and Siemens. In one reported instance, the actors utilized Dropbear Secure Shell (SSH) software on victim modems to enable them to gain remote access through port 22 [T1219].

Exfiltration

(New, July 22, 2026) The authoring agencies observed Iranian-affiliated APT actors using configuration software—such as Rockwell Automation’s Studio 5000 Logix Designer, Schneider Electric’s EcoStruxure Control Expert, and Siemens’ Totally Integrated Automation (TIA) Portal—on leased, third-party hosted infrastructure to exfiltrate device project files from PLC devices to threat-actor-controlled infrastructure [T1041].

Impact

(Updated, July 22, 2026) After the actors extracted device project files, the FBI and CISA identified the modification and deletion of project file logic, to include Add-On Instructions (AOIs) and data manipulation on HMI and SCADA displays [T1565]. Additionally, the changes disabled critical shutdown and alarm logic, allowing systems to enter unsafe conditions without notifying operators of the anomalies.

Note: An AOI is analogous to a “Function Block” or “User Defined Function Block” used in other PLC vendor programs.

Indicators of Compromise

See Table 1 and Table 2 for recent IP addresses used by the Iranian-affiliated APT actors to communicate with PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, and Siemens in the United States.

Disclaimer: The FBI observed the threat actors using the IP addresses listed below in the specified time frames. This data is being provided for customers to query against logs for indications of historical targeting by the Iranian-affiliated APT actors. The authoring agencies recommend organizations investigate or vet these IP addresses prior to taking action, such as blocking.

MITRE ATT&CK Tactics and Techniques

See Table 3 to Table 6 for all referenced threat actor tactics and techniques in this advisory. The authoring agencies recommend organizations review historical TTPs for similar Iranian-affiliated cyber actor activity in IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

Mitigations

The authoring agencies recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of the threat actors’ activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats and TTPs. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

Network Defenders

The cyber threat actors accessed PLCs manufactured by Rockwell Automation/Allen-Bradley, Schneider Electric, Siemens, and potentially other branded/manufactured PLCs to cause disruptions to victim systems. To safeguard against this threat and threats to other types of PLCs, the authoring agencies urge organizations to consider the following mitigations.

(Updated, July 22, 2026) In addition to contacting the authoring agencies, organizations and integrators operating PLCs from the manufacturers mentioned in this advisory should review the previously issued guidance to strengthen the security of their OT deployments:

• Rockwell Automation: Contact the Rockwell Automation Product Security Incident Response Team (PSIRT) at PSIRT@rockwellautomation.com for questions regarding this guidance, or to report cyber incidents related to Rockwell Automation products.
  
  • Refer to Rockwell Automation Security Advisory SD1771 for recommended PLC hardening measures and configuration guidance.
• Schneider Electric: Contact the Schneider Electric Corporate Product Cyber Emergency Response Team (CPCERT) at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
  
  • Refer to Schneider Electric’s Recommended Cybersecurity Best Practices and Cybersecurity User Guide for Modicon Controller Platform for guidance on securing and configuring PLCs.
• Siemens: Contact Siemens ProductCERT at productcert@siemens.com for questions regarding this guidance, or to report cyber incidents and vulnerabilities related to Siemens products.
  
  • Refer to Siemens Security Bulletin 104599 for a list of security measures to harden PLCs and in-depth configuration guides.
  • Siemens users should review the Cybersecurity for Industry Operational Guidelines and implement defense-in-depth controls within their automation systems.

Immediate steps to prevent the attack:

• Disconnect the PLC from the public-facing internet [CPG 3.S]. Follow the joint guidance Secure connectivity principles for OT to safely allow remote access. Specifically, “remove inbound port exposure,” so the OT system is never directly exposed to the internet or external networks, and to ensure all access is mediated, monitored, and controlled. Do this through a secure gateway (jump host) that brokers the connection.
  
  • Ensure cellular modems, used for remote field connectivity and access, are secured with strong authentication and updated.
  • Enable logs for connected modems and regularly review for suspicious activity to detect intrusions and improve incident response speed.
  • (New, July 22, 2026) To mitigate unauthorized access to OT via cellular modems, organizations should consider implementing isolated architectures, such as private Access Point Name (APN), 5G Public Network Integrated Non-Public Network (PNI-NPN), cellular Software-Defined Wide Area Network (SD-WAN), Zero Trust Network Access (ZTNA), or a site-to-site virtual private network (VPN).
• (New, July 22, 2026) Strictly control network access to PLC devices.
  
  • Configure firewall rules or access control list (ACL) security features on PLCs or programmable controllers to allow only authorized communications between expected control system devices. Block access from unauthorized or threat actor-controlled IP addresses, such as those associated with hosting providers.
• For controllers with a physical mode switch, place the physical mode switch into run position to prevent remote modification. Devices should only be in the program or remote position when updating or downloading software online and immediately switched back to the run position when complete. (See Rockwell Automation’s² System Security Design Guidelines for manufacturer’s instructions.)
  
  • (New, July 22, 2026) Prior to switching the device to run mode, review and validate project files, as changing modes will lock in the current project file downloaded to the device.
• For devices that allow software key switching, enable programming protection in PLC configuration software (S7 TIA Portal) to limit who can modify PLCs remotely. (See Siemens’ Cybersecurity for Industry Operational Guidelines for the manufacturer’s instructions.)

Follow-up steps to strengthen security posture:

• (New, July 22, 2026) Review project files running on PLCs for unauthorized changes. Use vendor-provided integrity checking tools and visually compare the running program to known good logic. Ensure reusable logic and input/output configurations are valid. For Rockwell Automation PLCs listed in the Customer Guidance to Disconnect Devices from the Internet, check the AOIs for any anomalous modifications.
  
  • If restoring from backups, verify the backup does not contain malicious logic before deployment.
  • Review logs and configurations on all connected devices, including modems, HMIs, and workstations, to assess potential lateral movement by threat actors. If it appears the actors connected to additional devices, reimage these devices to remove any potential malicious changes or access tools.
• (New, July 22, 2026) Ensure device passwords are changed from their default and are configured to use complex, unique combinations of letters, numbers, and symbols that are not easily guessable. Implementing robust password practices remains a critical security measure that can help prevent unauthorized access and strengthen the overall security posture of OT devices.
• (New, July 22, 2026) Take defensive measures to minimize the risk of exploitation. Conduct comprehensive impact analysis and risk assessments prior to deploying defensive measures.
• Create and test strong backups of the logic and configurations of PLCs. Store backup files offline and secure the physical removal media to enable fast recovery.
• Implement multifactor authentication (MFA) [CPG 3.F] for access to the OT network from an external network.
• If remote access is required, implement a network proxy, gateway, firewall, and/or VPN in front of the PLC to control network access.
  
  • A VPN or gateway device can enable MFA for remote access even if the PLC does not support MFA. Implement security rules on these higher-level network security mechanisms to prevent the type of repeated and sustained login attempts seen during a brute force attack. When possible, implement a device control list for workstations sending messages or connecting to OT components.
  • Use the device control list to monitor for logon activity for unexpected or unusual access to devices from the internet.
• Keep PLC devices updated with the latest software patches issued by the manufacturer. Use established downtime windows to install patches. Known Exploited Vulnerabilities may need to be prioritized outside a downtime window.
• Configure external and internal firewalls to block traffic using common ports associated with network protocols that are unnecessary for the particular network segment.
• Disable any unused authentication methods, logic, or features, such as default authentication keys and passwords, as well as unused or needed services such as Teletype Network (Telnet), File Transfer Protocol (FTP), Remote Desktop Protocol (RDP), Virtual Network Computing (VNC), and web services.
• Monitor asset management systems for device configuration changes, which can be used to understand expected parameter settings.
• Monitor the content of network traffic for the following:
  
  • Unusual logins to internet-connected devices or unexpected protocols to/from the internet. 
  • Functions of industrial control systems management protocols that change an asset’s operating mode or modify programs.
• (New, July 22, 2026) Ensure service providers are informed of active threats targeting internet-connected PLC devices. Owners and operators should communicate directly with service providers to address risks, especially when remote monitoring or maintenance is involved. Some service providers may rely on internet connectivity essential to monitor and maintain OT/ICS operations but may not be fully aware of active threats.

In addition, the authoring agencies recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques, as well as reduce the impact and risk of compromise by cyber threat actors:

• Reduce risk exposure. CISA offers a range of services at no cost, including scanning and testing, to help organizations reduce exposure to threats via mitigating attack vectors. CISA’s Cyber Hygiene Services can help provide additional review of organizations’ internet-accessible assets. 

Device Manufacturers

Note: The following guidance is general in nature and not specific to any OT vendor. Some of the features, settings, and practices may already be offered by certain vendors. The inclusion of this guidance should not be interpreted as an assertion that vendors referenced do not offer such security features. Also, this advisory is not highlighting a new vulnerability in the identified products, but instead discusses opportunistic targeting. Device manufacturers can make opportunistic attacks more difficult at scale by encouraging more secure behavior by default and in operations, as discussed below. 

Although critical infrastructure organizations using PLC devices can take steps to mitigate the risks, it is ultimately the responsibility of the device manufacturer to build products secured by design and default. The authoring agencies urge device manufacturers to take ownership of their customers’ security outcomes by following the principles in the joint guide Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products, primarily:

• Change the manufacturers’ default settings to prevent exposing administrative interfaces to the internet.
• Do not charge additional fees for basic security features needed to operate the product securely.
• Support MFA, including via phishing-resistant methods.

By using secure by design tactics, software manufacturers can make product lines secure “out of the box” without requiring customers to spend additional resources making configuration changes, purchasing tiered security software and logs, monitoring, and making routine updates.

For more information on common misconfigurations and guidance on reducing their prevalence, see joint advisory NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations. For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

Validate Security Controls

In addition to applying mitigations, the authoring agencies recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3 to Table 6).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The authoring agencies recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the ATT&CK techniques identified in this advisory.

Resources

• Authoring Agencies: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities
• CISA: Bulletproof Defense: Mitigating Risks From Bulletproof Hosting Providers
• EPA: Cybersecurity for the Water Sector
• CISA: Water and Wastewater Cybersecurity
• CISA: Exploitation of Unitronics PLCs used in Water and Wastewater Systems
• CISA: Iran Threat Overview and Advisories
• FBI: The Iran Threat and Cyber Threat Overview: Iran
• CISA, MITRE: Best Practices for MITRE ATT&CK Mapping
• CISA: Decider Tool
• CISA: Cross-Sector Cybersecurity Performance Goals 2.0
• CISA: No-Cost Cybersecurity Services and Tools
• CISA: Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products
• NSA, CISA: NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations
• CISA: Secure by Design
• FBI, CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• United Kingdom National Cyber Security Centre: Secure connectivity principles for operational technology

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, the FBI, and/or NSA:

• Contact CISA via CISA’s 24/7 Operations Center at contact@cisa.dhs.gov or 1-844-Say-CISA (1-844-729-2472). File a claim with FBI’s Internet Crime Complaint Center (IC3) or contact your local FBI field office. When available, please include the following information regarding the incident: 
  • Date, time, and location of the incident;
  • Type of activity;
  • Number of people affected;
  • Type of equipment used for the activity; and
  • Name of the submitting company or organization, and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.
• Entities required to report incidents to DOE should follow established reporting requirements, as appropriate. For other energy sector inquiries, contact EnergySRMA@hq.doe.gov.
• Contact the Rockwell Automation PSIRT for questions regarding their guidance or for reporting cyber incidents related to Rockwell Automation products at PSIRT@rockwellautomation.com.
• Contact the Schneider Electric CPCERT at cpcert@se.com for questions regarding this guidance, or to report cyber incidents related to Schneider Electric products.
• Contact Siemens ProductCERT for up-to-date information about the security of Siemens products or to report cybersecurity vulnerabilities at productcert@siemens.com. For support with increasing the security of installed Siemens PLCs, contact Siemens Industrial Cybersecurity Services at services.automation@siemens.com. See Siemens ProductCERT and Siemens CERT for more information.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. CISA and the authoring agencies do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and the authoring agencies.

Version History

April 7, 2026: Initial version.

July 22, 2026: Update includes new guidance on detecting malicious activity, expanded scope of observed targeting, and best practices for secure PLCs deployment.

Notes

¹Project file refers to the software file that contains ladder logic and configuration settings. On Rockwell Automation devices, it is referred to as an .ACD file.

² See CompactLogix 5370 Controllers (Chapter 5: “Select the Operating Mode of the Controller”) for more information on functions available for the switch.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

Researchers from ETH Zurich in Switzerland, however, managed to create a new type of pixel that can simultaneously do both. This hypercharged pixel, called a Fourier pixel, can generate and sense arbitrary light fields and tap into a pixel’s full potential for carrying information by manipulating light’s intensity, oscillation phases, and polarization. The team reported its findings in a paper published yesterday in Nature.

We are one step closer to 1984 technology:

The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plaque commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment...

Paper.

Abstract: This Article updates and expands on 2012 research on encryption and globalization, analyzing what the authors call “Round 3” of the Going Dark Debate: the current controversies over end-to-end encryption (E2EE). Governments around the world have proposed, and in some cases enacted, laws limiting E2EE for law enforcement and national security purposes.

This Article explains the underlying technologies and market developments for a law and policy audience to assess those proposals critically. The Article proceeds in three parts tracking three rounds of the Going Dark Debate. Round 1 covers the Crypto Wars of the 1990s, when U.S. export controls on strong encryption ultimately fell in 1999. Round 2 covers the period roughly 2010 to 2015, when encryption-in-transit became widespread but lawful access remained available through cloud providers, giving rise to what the authors called a “golden age of surveillance” rather than a period of going dark. Round 3 addresses the current debate over E2EE, where no entity between sender and recipient can read the plaintext...

❤️ Check out Weights & Biases and sign up for a free demo here: https://wandb.me/papers

📝 The paper is available here:
https://github.com/google-deepmind/alphaproof-nexus-results
https://arxiv.org/html/2605.22763v1

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

My research: https://cg.tuwien.ac.at/~zsolnai/
Thumbnail design: https://felicia.hu

Thanks to Micro Center for sponsoring this video! Shop Micro Center's Laptop Savings Event: https://micro.center/a00204

Sign up for a FREE 128 gig Flash Drive at Micro Center Austin, TX: https://micro.center/74ccbf
Sign up for a FREE 128 gig Flash Drive at Micro Center Columbus, OH: https://micro.center/4aed40
Visit Micro Center News: https://micro.center/368232

DLSS 5 is here, and it's not what you think. Nvidia's calling it the biggest graphics leap since Ray Tracing, but the same audience that defended DLSS for eight years is calling this one AI slop. So what's actually going on?

In this video, we break down what DLSS 5 actually does, how neural rendering works, why Nvidia's CEO and Nvidia's own engineers are describing the tech differently, and whether the backlash from gamers and developers is justified.

Leave a reply with your requests for future episodes.

► SHOP OUR PRODUCTS: https://lttstore.com
► GET A VPN: https://www.piavpn.com/TechQuickie
► GET EXCLUSIVE CONTENT ON FLOATPLANE: https://lmg.gg/lttfloatplane
► SPONSORS, AFFILIATES, AND PARTNERS: https://lmg.gg/partners

Chapters
------------------------
00:0 DLSS backstory
1:20 DLSS 5 explained
2:20 Why gamers are confused
2:40 Sponsor
3:14 DLSS 5 unmasked
4:30 Why gamers are mad
6:00 Watch another video

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The Nemotron 3 Ultra paper is available here:
https://research.nvidia.com/labs/nemotron/Nemotron-3-Ultra/

Free Rendering course and source code:
https://users.cg.tuwien.ac.at/zsolnai/gfx/rendering-course/

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

Thumbnail design: https://felicia.hu

#nvidia

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The paper is available here:
https://www.anthropic.com/research/natural-language-autoencoders
https://transformer-circuits.pub/2026/nla/index.html

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

My research: https://cg.tuwien.ac.at/~zsolnai/
Thumbnail design: https://felicia.hu

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The paper is available here:
https://arxiv.org/abs/2602.21548

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

#deepseek

❤️ Check out Weights & Biases and sign up for a free demo here: https://wandb.me/papers

📝 The paper is available here:
https://arxiv.org/abs/2506.06494

Sources:
https://www.youtube.com/shorts/Tx7167DXr8U
https://www.youtube.com/watch?v=55F9dY2Y1zc

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The paper is available here:
https://xandergos.github.io/terrain-diffusion/
https://modrinth.com/mod/terrain-diffusion
https://github.com/xandergos/terrain-diffusion

Source video for some parts of the footage: https://www.youtube.com/watch?v=irE4tcDtUIg

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The paper is available here:
https://transformer-circuits.pub/2025/linebreaks/index.html

Paper for reindeer vision change - https://royalsocietypublishing.org/rspb/article/280/1773/20132451/50765/Shifting-mirrors-adaptive-changes-in-retinal

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

❤️ Check out Lambda here and sign up for their GPU Cloud: https://lambda.ai/papers

📝 The paper is available here:
https://www.anthropic.com/research/AI-assistance-coding-skills

🙏 We would like to thank our generous Patreon supporters who make Two Minute Papers possible:
Adam Bridges, Benji Rabhan, B Shang, Cameron Navor, Charles Ian Norman Venn, Christian Ahlin, Eric T, Fred R, Gordon Child, Juan Benet, Michael Tedder, Owen Skarpness, Richard Sundvall, Ryan Stankye, Shawn Becker, Steef, Taras Bobrovytsky, Tazaur Sagenclaw, Tybie Fitzhugh, Ueli Gallizzi

The model, available immediately on all of Anthropic's platforms, is priced at $5 per million input tokens and $25 per million output tokens, unchanged from its predecessor, Opus 4.8. It becomes the new default model on Claude Max, Anthropic's premium consumer tier, and the strongest model available on Claude Pro.

The positioning is deliberate. Anthropic is not claiming Opus 5 is its smartest model — that distinction still belongs to Fable 5, and rival systems retain an edge in certain domains. Instead, the company is making a subtler argument that may matter more to enterprise buyers: that the most economically important AI work happens in a middle band of difficulty, where near-frontier intelligence delivered efficiently and cheaply beats frontier intelligence delivered expensively.

"Opus 5 as your daily driver, the model you hand complex work to and review when it's done," an Anthropic spokesperson said in an interview with VentureBeat, describing how the company's lineup now stratifies. "Fable 5 for your most ambitious work, the days-long autonomous projects nothing could take on before... Sonnet 5 for work you run at scale, where speed and cost per call decide what ships. Haiku 4.5 for subagents and instant answers."

How Claude Opus 5 benchmark results stack up against Fable 5 and rival AI models

On paper, the results are striking. Anthropic says Opus 5 sets new state-of-the-art marks on coding and knowledge-work evaluations including Frontier-Bench and GDPval-AA. On Frontier-Bench v0.1, an agentic terminal coding benchmark, Opus 5 scores 43.3 percent — more than double Opus 4.8's 18.7 percent and well ahead of Fable 5's 33.7 percent — at a lower cost per task, according to the company. On ARC-AGI 3, an evaluation of novel problem-solving, Anthropic reports Opus 5 scored three times as high as the next best model. On OSWorld 2.0, a computer-use benchmark, the company says the model surpasses Fable 5's best result at just over a third of the cost.

The numbers come with honest caveats that are themselves notable in an industry prone to superlatives. Anthropic acknowledges Opus 5 remains behind Mythos 5, a competing model, on cybersecurity tasks and biology research, and an OpenAI-family model still leads on one agentic coding benchmark.

The more revealing caveat came from Anthropic itself, when asked where Opus 5 still falls short of Fable 5. The spokesperson's answer amounted to a candid admission about what benchmarks do and don't capture.

"The evals where Opus 5 wins are bounded tasks with a specific outcome, which is where it's strongest. What those evals don't measure is duration," the spokesperson told VentureBeat. "One way to put it: Opus 5 is the best tool for the jobs benchmarks can see, and Fable 5 is what you reach for when the job outruns the benchmark."

Fable 5, by contrast, "is for the longest, most autonomous jobs, where the model has to stay coherent across many connected steps over hours or days with dense source material," the spokesperson said, advising customers to "run both on a representative workload, one bounded task and one long-horizon job." That framing — bounded tasks versus long-horizon autonomy — may become the defining axis of model differentiation in 2026, as benchmarks saturate and the hardest remaining problems involve sustained, multi-day agentic work rather than discrete puzzles.

Why token efficiency is becoming the real battleground for enterprise AI spending

Threaded through the launch is a theme Anthropic clearly wants buyers to absorb: Opus 5 doesn't just score well, it scores well per dollar. The model ships with an adjustable "effort" setting that lets customers trade intelligence for speed and token savings, and Anthropic's charts emphasize performance at a given cost rather than peak performance alone.

Early customers echoed the point with unusual specificity. Harvey, the legal AI company, said Opus 5 achieved similar performance to Opus 4.8's maximum-reasoning mode "while generating 26% fewer tokens on average," according to Niko Grupen, its head of applied research. Richard Pham of Fundamental Research Lab said that on hard financial-modeling tasks, the model averaged nine percentage points higher accuracy "while using roughly one-third fewer turns and tool calls and 60% less time."

Wade Foster, chief executive of Zapier, said Opus 5 topped his company's AutomationBench leaderboard "without spending more tokens than prior Claude models," running a full churn-prevention workflow from start to finish. "Previous models didn't pass; Opus 5 hit 100%," he said. Scott Wu, chief executive of Cognition, the company behind the Devin coding agent, said that on FrontierCode 1.1, "Claude Opus 5 approaches Fable-level performance at half the cost," with particular strength in debugging and root-cause analysis.

The efficiency emphasis reflects commercial reality. Enterprise AI spending is no longer experimental, and inference costs — the price of actually running these models at scale — have become a board-level line item. 

Anthropic's business skews heavily toward API and enterprise usage; according to a February 2026 analysis by Contrary Research, Claude held roughly 40 percent of the enterprise large language model market by usage as of late 2025, and Claude Code alone had reached about $1 billion in annualized revenue. For a company whose customers pay by the token, a model that does more with fewer tokens is not a nice-to-have. It is the product.

Self-verifying AI agents and what they mean for the hidden costs of automation

Beyond the numbers, Anthropic is selling a behavioral story: that Opus 5 verifies its work and iterates until it succeeds. The company offered several examples from testing that read like small parables of machine stubbornness.

In one Frontier-Bench task, the model was asked to reconstruct a machine part as a 3D CAD model from a drawing it was intentionally given no way to view. Rather than fail, Anthropic says, Opus 5 wrote its own computer vision pipeline to extract the geometry from raw pixels — and did so repeatedly, while no competing model solved the task in five attempts. In another case, given a real bug in a popular open-source package manager, the model found the root cause and fixed an edge case the community's own patch had missed; a competing model patched only the symptom and declared victory. An engineer at a trading firm, the company says, used Opus 5 to build a market data feed for a new exchange in a single session and, finding no live feed to validate against, watched the model build its own test harness to check its parsing code.

Customers described similar behavior in the wild. Cristian Rivera, a staff software engineer at Stripe, said he gave the model "a chief-of-staff role over my dev environments" for a weekend: "it built its own monitor, drove each box, and pulled me in only for the judgment calls."

This is the capability enterprises actually care about, and it is worth dwelling on why. The gap between a model that produces plausible output and one that verifies its output is the gap between a demo and a deployable system. Most of the hidden cost of enterprise AI today is human review — engineers checking the machine's work. A model that reliably checks its own work compresses that cost, which is precisely why customers keep citing fewer turns, fewer passes, and less time rather than higher raw scores.

Inside Anthropic's safety strategy: capability gaps, classifiers, and model fallbacks

The launch also showcases Anthropic's increasingly intricate approach to safety — one that now involves deliberately not teaching its models certain skills. The company says its automated behavioral audit found Opus 5 to be its most aligned model to date, scoring 2.3 on overall misaligned behavior, lower than Opus 4.8, Sonnet 5, or Fable 5, with the lowest rates of deceptive behavior and the least susceptibility to being tricked into misuse.

On the capability side, Anthropic says it intentionally avoided training Opus 5 on cyber tasks, as it did with Opus 4.8. The model improved on them anyway — a side effect of general capability gains — and now nearly matches Mythos 5 at finding software vulnerabilities. But it remains far behind at exploiting them: on Anthropic's OSS-Fuzz evaluation, Opus 5 identified vulnerabilities at a 79.4 percent rate, close to Mythos 5's 80 percent, but succeeded at developing exploits in only 4 challenges versus Mythos 5's 13. That asymmetry — strong at defense-relevant discovery, weak at offense-relevant exploitation — appears to be by design, and the safeguards follow the same logic. Anthropic expects Opus 5's cyber classifiers to intervene about 85 percent less often than Fable 5's.

When a classifier does trigger, requests in Claude.ai, Claude Code, and Claude Cowork fall back to Opus 4.8 by default — raising an obvious question: if a request is too risky for one model, why is it acceptable for another? "The model it falls back to has lower capability levels making the risk of harmful use lower as well," the spokesperson said, adding that "there is a message that lets the user know when this occurs and is visible in the chat."

The logic is defensible, but it reveals how AI safety actually works in 2026: risk is not a property of the question alone, but of the question multiplied by the capability of the system answering it. On biology, the calculus runs the other way. Opus 5 is now Anthropic's most capable generally available model for scientific research — scoring 10.2 percentage points higher than Opus 4.8 on the company's internal chemistry benchmark — though the spokesperson acknowledged that "Mythos 5 remains the stronger model for long-horizon, open-ended work like autonomous drug design campaigns."

The business stakes behind the launch: a $380 billion valuation and massive compute bets

The launch lands at a moment of extraordinary commercial momentum — and extraordinary obligations — for Anthropic. Reuters reported in February that the company was valued at roughly $380 billion in its latest funding round, following a period in which, per Contrary Research's analysis, its annualized revenue climbed from about $1 billion at the end of 2024 to a projected $9 billion by the end of 2025, with internal targets reportedly reaching $20 to $26 billion for 2026. Those targets are underwritten by enormous infrastructure commitments, including a reported $30 billion Azure compute deal alongside arrangements with Google Cloud and Nvidia — spending that only pencils out if enterprises keep expanding usage.

That is the context in which Opus 5's pricing strategy makes sense. Holding the price at Opus 4.8 levels while roughly doubling performance on key agentic benchmarks is effectively a steep price cut per unit of capability, designed to widen the funnel of workloads that are economical to automate. Every task that was marginal at Opus 4.8's cost-per-success becomes viable at Opus 5's — and every viable task is recurring token revenue.

The regulatory backdrop has grown more complex as well. A U.S. judge gave final approval this week to Anthropic's $1.5 billion copyright settlement with book authors, Reuters reported, closing a chapter of litigation over the company's early training data. And in June, Reuters, citing Axios, reported that the U.S. government had moved to block foreign access to Anthropic's most advanced models — a reminder that frontier AI is now entangled with export policy in ways that shape which customers can buy what.

Also shipping Friday: a Fast mode running at roughly 2.5 times default speed at twice the base price, automatic fallback routing on the API, and mid-conversation tool changes that no longer invalidate the prompt cache — a small feature that agent developers may appreciate more than any benchmark. Consistent with prior Opus models, Opus 5 carries no data retention requirements for general access, a point the spokesperson flagged unprompted for customers with "a hard zero data retention requirement." Developers can access the model as claude-opus-5 on the Claude API starting today.

Two questions will determine whether the bet pays off: whether Opus 5's efficiency claims survive contact with production workloads at scale, and whether enterprises embrace a world where safety classifiers, not users, sometimes decide which model answers. But the deeper message of Friday's launch is that the AI industry's center of gravity has moved. For three years, the labs competed on what their best model could do on its best day. With Opus 5, Anthropic is competing on something less glamorous and far more lucrative: what a very good model can do every day, for half the price. In a market where the frontier keeps moving, Anthropic is wagering that the real fortune lies just behind it.

The post Context Windows Forget What Matters — I Built a Usage-Reinforced Decay Engine for AI Agent Memory appeared first on Towards Data Science.

Summary

Successful exploitation of this vulnerability could allow an authenticated attacker to write arbitrary files to restricted system directories outside of the application's intended directory.

The following versions of Rockwell Automation ThinManager are affected:

• ThinManager >=13.0.0|<13.0.7, >=13.1.0|<13.1.5, >=13.2.0|<13.2.4, >=14.0.0|<14.0.2

Background

• Critical Infrastructure Sectors: Chemical, Critical Manufacturing, Energy, Food and Agriculture, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an attacker with network access to achieve remote code execution.

The following versions of Johnson Controls C-CURE 9000 and Victor application server are affected:

• C-CURE 9000 and victor <=v2.90_v3.0 
• victor Web <=v7.1 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Ireland

Vulnerabilities

Acknowledgments

• Harrison Neal reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities. CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could result in an attacker obtaining confidential information from the device.

The following versions of Johnson Controls XAAP Android are affected:

• XAAP Android <1.53

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Ireland

Vulnerabilities

Acknowledgments

• Johnson Controls reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an unauthenticated network-adjacent attacker to crash critical IEC 61850 services or execute arbitrary code, disrupting or compromising protection, visibility, and control functions.

The following versions of MZ Automation libIEC61850 are affected:

• libIEC61850 >=v1.0.0|<=v1.6.1 

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Energy, Transportation Systems
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Abhinav Agarwal reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could cause the parsing process to crash, which will cause a denial of service.

The following versions of MZ Automation lib60870 are affected:

• lib60870 <=2.4.0

Background

• Critical Infrastructure Sectors: Chemical, Energy, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Lars Tray reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this (these) vulnerability(ies).

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow an attacker with access to the IT network to manipulate industrial control devices without requiring physical access, specialized insider knowledge, or advanced tooling.

The following versions of Panduit IntraVUE are affected:

• IntraVUE <=3.2.1a14 

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Energy, Information Technology, Water and Wastewater
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Netherlands

Vulnerabilities

Acknowledgments

• Phlebas of Lumintel reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the Internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow a non-privileged user to escalate privileges or view the credentials of other users.

The following versions of Weintek cMT3092X are affected:

• cMT3092X firmware <20210218 
• EasyWeb <v2.1.20

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Taiwan

Vulnerabilities

Acknowledgments

• Vincenzo Giuseppe Colacino of Secoore reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take the following measures to protect themselves from social engineering attacks:

Practice principles of least privilege.

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-23

Legal Notice and Terms of Use

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.

Read more →

The post End-to-End Encryption and “Going Dark” appeared first on IT Security News.

Abstract: This Article updates and expands on 2012 research on encryption and globalization, analyzing what the authors call “Round 3” of the Going Dark Debate: the current controversies over end-to-end encryption (E2EE). Governments around the world have proposed, and in some cases enacted, laws limiting E2EE for law enforcement and national security purposes.

This Article explains the underlying technologies and market developments for a law and policy audience to assess those proposals critically. The Article proceeds in three parts tracking three rounds of the Going Dark Debate. Round 1 covers the Crypto Wars of the 1990s, when U.S. export controls on strong encryption ultimately fell in 1999. Round 2 covers the period roughly 2010 to 2015, when encryption-in-transit became widespread but lawful access remained available through cloud providers, giving rise to what the authors called a “golden age of surveillance” rather than a period of going dark. Round 3 addresses the current debate over E2EE, where no entity between sender and recipient can read the plaintext...

The company launched Inflection AI Labs, a public-facing research and experimentation arm, alongside Pi Journeys, the lab's first product experiment — an AI experience designed to adapt to a user's life stage, whether that's becoming a parent, taking on caregiving duties, changing careers, or aging. The announcement arrived with a research report on consumer AI habits and a substantial update to Pi, the company's flagship chatbot, adding improved voice, memory, and new agentic tools for reminders, to-do lists, and shopping.

"Inflection AI is the company. Pi is our flagship consumer product. Inflection AI Labs is where we experiment, explore personal intelligence and share more publicly. Pi Journeys is the first public experiment from Inflection AI Labs," CEO Sean White told VentureBeat in an exclusive interview.

Behind the tidy org chart is a far more interesting story: a company attempting one of the more unusual second acts in the AI industry, powered by an argument that the entire market is optimizing for the wrong thing.

Why Inflection AI believes the chatbot era's biggest flaw is that it's transactional

White's central claim is that today's AI assistants — including the industry's most capable models — are fundamentally transactional. You ask, they answer, the session ends. He believes that architecture misses most of what people actually need from artificial intelligence in their daily lives.

"One of the things that really struck us in particular, and this showed up in the research, was that a lot of the work is very transactional, and you'll hear me say a lot that we've been shifting all this from transactional to relational systems," White said. "Not everything is going to be: I do a single turn, I utter a question, I get a search response back."

White frames the industry's evolution as a progression through four kinds of intelligence. First came raw IQ — the foundation model race. Then emotional intelligence, which Inflection made its signature with Pi's famously warm conversational style. Then agentic intelligence — AI that acts rather than just talks — which White says Inflection absorbed from its enterprise work. The fourth, and the one Inflection is now staking its future on, is what the company calls relational intelligence: AI that understands not just you, but the web of people around you.

"There's so much fear about these things pushing people into loneliness,” White said. “If we design these pro-social systems as another design criteria, that actually makes a huge difference."

That design philosophy is a pointed counter-narrative to one of the loudest anxieties in consumer AI right now: that emotionally engaging chatbots deepen isolation by substituting for human contact. Inflection argues the opposite is possible — that an AI with structured knowledge of your relationships can push you back toward people rather than away from them.

Inside Pi Journeys, the AI companion that maps your relationships and life stages

Pi Journeys makes that idea concrete. When users first open the product, it asks about their life stage — caregiver, household manager, midlife transition — and then builds what White describes as specially structured memory around the people who matter in that context. From there, the system becomes proactive.

"It starts to build up memories around that, and it acts as a memory prosthetic — but in a pro-social way," White said. "It doesn't get in the way of your interactions with other people; it really helps facilitate them." The system might remind a user, for example, that a friend deserves a call, or resurface what was last discussed with a family member involved in a parent's care.

White, who spent years as chief R&D officer at Mozilla before taking Inflection's helm, was quick to flag the obvious privacy implications of an AI that maps your social graph. "We've built a lot of privacy systems into this," he said, noting users can delete and manage the people recorded in their profile. Whether consumers will trust a venture-backed AI company with a structured database of their most important relationships remains one of the biggest open questions hanging over the product — and one that enterprise buyers evaluating Inflection's technology will watch closely.

Asked why this was the first Labs experiment, White was direct: "Pi Journeys takes into account people's life stages and experiences because we have heard from users that we can provide more value in helping them navigate their lives. Pi Journeys lets us experiment with the early stages of prosocial and relational intelligence because life isn't single-player."

The product has been tested internally and with small closed groups, White said, and is now being released more broadly as an experiment rather than a finished product — a posture the Labs branding is designed to make explicit.

What Inflection's consumer AI research reveals about how people actually use chatbots

Inflection Labs' first publication, the State of Consumer AI Research Report, offers the empirical scaffolding for the strategy. The average consumer now uses roughly two different AI tools every day and three per week, the company found — evidence, in Inflection's reading, that no single assistant has locked up consumer loyalty and that the market remains contestable.

More telling is why people choose the tools they do. Respondents cited personalization, style and tone, context awareness, and — notably — emotional understanding as deciding factors. They also said they want AI to be more than a productivity engine: a coach or mentor to motivate them, a chef to suggest recipes, a DJ to curate playlists.

"One thing we're certainly finding is that a lot of that also is in work, not so much in everyday life," White said. "That's our focus right now — the everyday life part."

This is a shrewd reading of the competitive map. The best-funded AI labs are pouring resources into coding tools, enterprise agents, and developer platforms, leaving everyday consumer use cases comparatively underserved. White sees the gap clearly. "We see a lot of products that are being aimed more and more at the enterprise," he said. "As a computer scientist by training, I kind of love the IDEs as this tool, but it's not really great for everybody. There's so much regular everyday use from folks that is either purely voice or that is purely mobile."

He recalled a conversation with a conference staffer who told him she owned only a phone, no laptop — exactly the kind of user, he argued, that the industry's developer-centric product roadmaps have left behind.

How the $650 million Microsoft deal hollowed out Inflection — and set up its second act

To understand why any of this is remarkable, you have to rewind to March 2024. Inflection was then one of the hottest startups in AI, having raised $1.3 billion in mid-2023 in a round backed by Microsoft, Nvidia, Bill Gates, and Reid Hoffman — more than $1.5 billion in total. Pi had crossed one million daily active users, per Reuters.

Then, in a deal that reshaped how the industry thinks about acqui-hires, Microsoft hired away co-founder and CEO Mustafa Suleyman, chief scientist Karén Simonyan, and most of the company's roughly 70 employees, paying Inflection about $650 million largely to license its technology, as Reuters reported. Suleyman now runs Microsoft's consumer AI business. The structure of the deal drew scrutiny from the FTC and Britain's competition regulator, though the UK's Competition and Markets Authority cleared it in September 2024 and EU regulators declined to act.

White, installed as CEO in the aftermath, steered the remnant company hard toward enterprise, acquiring three startups in late 2024 — Jelled.AI, BoostKPI, and the European consulting firm Boundaryless — and telling TechCrunch that November that Inflection had no intention of competing with companies building 100,000-GPU frontier systems.

Tuesday's announcement doesn't reverse that position so much as complicate it. Asked how to think about the company today, White called it "a consumer-first strategy that bridges both consumer and enterprise efforts" — and he insists the two sides feed each other.

Enterprise deployments, including a partnership with Intel that is among the few he can name publicly, taught Inflection how to run models inside complex infrastructure. Consumer products, meanwhile, let the company iterate at speed. "The part I also like about the consumer side, and this has always been true, is that we can move faster, experiment faster, and try and learn faster," White said.

The six-month prediction: relationship-aware AI is coming to the enterprise

Buried in White's consumer pitch is the claim that should matter most to technical decision-makers. "Normally I'd say like a year, but let's call it six months," he said. "You're going to start to see a bunch of enterprises care a lot more about the relationships that are inside the enterprises and what that picture is, not just the workflows."

If White is right, the wave of workflow-automation agents currently flooding the enterprise market is only the first phase of business AI adoption — with relationship-aware systems, tested first on consumers, following close behind. Inflection is essentially using its consumer products as a live laboratory for capabilities it plans to sell into companies. It's a capital-efficient strategy for a firm that can no longer outspend rivals on training runs, and a risky one, since it depends on consumers showing up in numbers large enough to generate the learning.

The technical substance underneath is equally pragmatic. Pi today runs not on a single proprietary frontier model but on an orchestration layer routing across many models — some descended from Inflection's original fully trained cores, some fine-tuned, some open source, including work with Nvidia that White says gives Inflection access to unreleased cutting-edge models. He also took a swipe at the industry's loose vocabulary around ownership: "When people say that the model is their own, most of the time nowadays — I guess I won't name names — a lot of companies will actually take a checkpoint, and then they will fine-tune from that checkpoint. But very few people actually start from that beginning core."

That candor extends to open source, where White carefully hedged. "We're not ready to promise what I think of as true open source, and by that I mean everything," he said, invoking his Mozilla years overseeing genuinely open projects like Rust and WebAssembly.

Weights without training data and pipelines, he argued, often leave developers unable to do anything meaningful with a supposedly "open" model. "We are a PBC, and there's still a C in there," he added — a reminder that public benefit corporations still have businesses to protect. The Labs will collaborate with academic researchers, including Stanford professors who visited the company's Palo Alto office this week, and continue contributing to open projects such as PyTorch.

Can a diminished Inflection compete with AI giants spending billions?

Reid Hoffman, the LinkedIn co-founder who co-founded Inflection and stayed on through the Microsoft upheaval, framed the announcement in the sweeping terms of his recent writing on AI and human agency. "Humans should be amplified by AI, not replaced. That's the principle Pi was built on," Hoffman said in the announcement. "When that kind of agency is available to everyone, you get superagency."

The skeptic's case is easy to make. Inflection is a fraction of its former size, competing for consumer attention against products from companies spending tens of billions of dollars a year. Pi's model was state of the art in 2023; it is not in 2026. And "relational intelligence" is, for now, a brand claim awaiting proof.

But the bull case is not crazy either. Inflection's own research shows consumers already juggle multiple AI tools and choose them for qualities — tone, emotional understanding, personalization — that frontier labs treat as afterthoughts. The company kept its technology, its Microsoft licensing windfall, and a defensible enterprise niche in on-premise, emotionally intelligent deployments. And it is targeting the one consumer segment — everyday, mobile-first, voice-first life management — that the coding-obsessed giants have largely ignored.

Asked what success looks like twelve months from now, White declined to talk numbers. "It's less about scale for scale's sake and more about scaling for impact by empowering people and improving their lives," he said. "Over the next year, success means leading the market towards relational intelligence and transforming AI interactions from transactional to relational."

Two years ago, Microsoft walked away with Inflection's founders, its staff, and its shot at the frontier — but it left behind the one idea the giants still haven't figured out how to build: an AI that knows the people in your life matter more than the tasks on your list. Inflection is betting the company, again, that the idea was the valuable part all along.

He pushed it further. “With AI-assisted or AI-generated code, that’s gonna be the future. It’s like all your thinking is gonna go into the evals.”

Amatriain served as VP of AI and Compute Enablement at Google across the platforms powering Gemini and Google Search before his December 2025 appointment at Expedia. He's mentored talent who went on to found Perplexity and Scale AI.

VentureBeat’s VB Pulse research on the evaluation gap reinforced the stakes. Sixty-six percent of the 157 enterprises surveyed already permit some production deployment without human review or are building toward it within the next 12 months, yet only 5% fully trust the automated evaluations that would make that decision. Half have shipped an agent that passed internal evals but then failed with a real customer.

Don’t let guardrails get in the way of feedback

“The more guardrails and artificial business rules and sort of rules that you put into the system, the worse off,” Amatriain said. “Not only because they’re brittle, but also because they actually mess up with the feedback loop. You are actually biasing the user and the feedback you get from the user, and then you’re learning that in the wrong way.” He called guardrails “a necessary evil” and said the goal is to minimize their impact over time.

Not everyone at Transform agreed. Other speakers argued during the event that the highest-risk actions still demand very firm guardrails.

Expedia governs AI through three layers instead. Principles come first, communicated broadly. “I like to encode at a very high level how I expect decisions to be made, because in a large organization you’re gonna have a lot of distributed decision making,” Amatriain said. “And sometimes, if you’re lucky enough, those principles might be embedded in your culture. But most of the time, my experience has been they’re not.” The processes and tools that enforce them follow. “Principles look really nice on a picture on some wall, but you need to then give them teeth,” he said. Automation sits on top of both.

In practice, this plays out through what Expedia calls agent release toll gates, checkpoints calibrated to risk. “Governance needs to correlate to the risk,” Amatriain said. “And if you have something that is low risk, you don’t need too much governance to get in the way. But if there’s a lot of risk, then you need more governance. That can be encoded.” The toll gates tie evaluation rounds, red teaming, and security review to each agent’s risk level, and the checks shift from recommended to required as the stakes climb.

Specialized agents over monolithic intelligence

“Even when I was at Google, I was like, I don’t believe in AGI as sort of like a singleton and a unified sort of like single model,” Amatriain told the audience. “I think it’s much better to think of it as composition, sort of like having specialized agents that are very good at some task and then composing the system out of those specialized agents.”

Expedia’s architecture starts at the component level. Tools compose into skills, skills assemble into sub-agents, and sub-agents get orchestrated into the full agentic system. “You need to have those principles that are unified that talk about things like what is the tone that we’re using, how are we addressing the user, how are we passing context, memory,” he said. “All of that needs to be thoroughly designed.” He framed this as a systemic design problem. “It’s not about the model, it’s not about a specific solution, it’s about how you’re designing the system.”

Amatriain argued that scoping each agent narrowly also makes the system easier to secure, since teams can evaluate and lock down individual agents in isolation before composing them.

When the user must keep the final click

Travel pricing changes in real time, flight availability shifts minute to minute, and hotel reviews routinely contradict what suppliers claim. Amatriain described a system that blends retrieval-augmented generation with direct API tool calls, choosing the approach based on latency. “If the user asks you a question like, how much does a four star hotel usually cost in Chicago in July, you don’t expect the agent to take two minutes to answer that question,” he said. “You expect an immediate answer because that answer can be cached and it doesn’t need real-time information.” A pet-friendly four-star near Lake Michigan with a pool might justify a 30-second reasoning window.

“The supplier might be saying, yeah, we have a great swimming pool, but then we also have the reviews from the travelers and we actually see there’s two reviews that say the swimming pool was not great or was not open after 6 p.m.,” Amatriain explained. A generic chatbot, he added, would only surface what a supplier self-reports, while Expedia cross-references against its own review corpus.

“We don’t want the agent to book the hotel or to buy you a plane ticket for you,” Amatriain said. “That’s something that the user has to have the agency. And the agent can recommend, can suggest, can discuss with you, but you’re gonna have to hit that click. And that’s non-negotiable.” That constraint, he argued, is also a security decision. “Once you establish those design principles, you also don’t need the guardrail because otherwise you’re gonna have to put all those guardrails in after the fact.”

The next attackers will be other AI systems

“Security needs to be a principle that is shifted as left as possible and as part of the design itself,” Amatriain said in response to an audience question. “And usually when you need a guardrail is because you’ve not thought about it early on.”

A second audience member pressed for lessons learned from production. Amatriain described a feedback loop where monitoring signals flow back into the eval suite. “You can almost automate the whole cycle,” he said. “But having that whole feedback loop from real signals, from your operating AI system, all the way into being reported and fixed as quickly as possible is going to become essential.”

Amatriain's toll gates are a bet that governance calibrated to risk can stay ahead of that feedback loop. VentureBeat’s separate June Pulse survey on agent security, drawn from 107 enterprises, shows how thin that margin is. More than half, 54 percent, have already had an agent security incident or near-miss. Fifty-nine percent plan to adopt, add, or replace agent security tooling within 12 months, and 29% plan to move this quarter. Incident rates climb with organization size, reaching 63% among enterprises with more than 1,000 employees versus 49% for companies with 101 to 1,000. And sandbox isolation, the one post-breach control that limits damage, drops from 35% adoption at the smaller companies to just 20 percent at the largest.

Amatriain warned that threats will increasingly come from other AI systems. “You’re gonna get threats coming not only from humans but also from other external agentic systems that are really powerful, and they’re gonna be poking at everything you’re doing. And as soon as you detect something, it’s not only about the detection, but the time to fix becomes essential here.”

Summary

Successful exploitation of these vulnerabilities could result in an attacker accessing sensitive credentials, disrupting connected infrastructure, or manipulating physical equipment, which could present a physical safety risk.

The following versions of Tycon Systems TPDIN-Monitor-WEB2 are affected:

• TPDIN-Monitor-WEB2 2.3.9 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Abdiwelli Guled reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

Multiple Siemens products are affected by unquoted search path vulnerability in IAM Client. This could allow an authenticated local attacker to perform privilege escalation. Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends countermeasures for products where fixes are not, or not yet available.

The following versions of Siemens IAM Client are affected:

• COMOS V10.4.5 vers:intdot/<10.4.5.0.2 
• COMOS V10.6 vers:intdot/<10.6.1 
• Designcenter NX vers:intdot/<2512.7000 
• Simcenter 3D vers:intdot/<2512.7000 
• Simcenter Femap V2506 vers:intdot/<2506.0003 
• Simcenter Femap V2512 vers:intdot/<2512.0002 
• Simcenter Nastran vers:intdot/<2606 
• Simcenter STAR-CCM+ vers:intdot/<2606 
• Solid Edge SE2025 vers:intdot/<225.0.13.3 
• Solid Edge SE2026 vers:intdot/<226.0.04.003 
• Teamcenter Visualization V2412 vers:intdot/<2412.0012 
• Teamcenter Visualization V2506 vers:intdot/<2506.0009 
• Teamcenter Visualization V2512 vers:intdot/<2512.2605 
• Tecnomatix Plant Simulation V2404 vers:intdot/<2404.0022 
• Tecnomatix Plant Simulation V2504 vers:intdot/<2504.0010 
• Tecnomatix Process Simulate vers:intdot/<2606 

Background

• Critical Infrastructure Sectors: Chemical, Critical Manufacturing, Energy
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported this vulnerability to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-288252 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Palo Alto Networks has published [1] information on vulnerabilities in PAN-OS. This advisory lists the related Siemens Industrial products affected by these vulnerabilities. Customers are advised to consult and implement the workarounds provided in Palo Alto Networks' upstream security notifications. [1] https://security.paloaltonetworks.com/

The following versions of Siemens RUGGEDCOM APE1808 with Palo Alto Networks Virtual NGFW are affected:

• RUGGEDCOM APE1808 vers:all/* 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-104023 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

CADRA is affected by multiple zlib and Foxit vulnerabilities. Siemens has released a new version for CADRA and recommends to update to the latest version. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.

The following versions of Siemens CADRA are affected:

• CADRA vers:intdot/<2511, vers:all/* 

Background

• Critical Infrastructure Sectors: Chemical, Commercial Facilities, Communications, Energy
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-470355 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow an attacker to impersonate an authorized user on the FTSP server, resulting in unauthorized access to system configurations.

The following versions of Rockwell Automation FactoryTalk Services Platform are affected:

• FactoryTalk Directory (FTSP) 6.60 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

SIDIS Secured SmartPlug before V7.26.0310 is affected by multiple vulnerabilities in the components OpenSSL, OpenSSH, and several other packages as described below. Siemens has released a new version of SIDIS Secured SmartPlug and recommends to update to the latest version.

The following versions of Siemens SIDIS Secured SmartPlug are affected:

• SIDIS Secured SmartPlug vers:intdot/<7.26.0310 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported these vulnerabilities to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of this vulnerability.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-585531 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of these vulnerabilities could allow for a local attacker to execute arbitrary files, alter configurations, or execute arbitrary code.

The following versions of Rockwell Automation Studio 5000 Logix Designer are affected:

• Studio 5000 Logix Designer V36.00 (CVE-2026-9108)
• Studio 5000 Logix Designer V35.00 (CVE-2026-9108, CVE-2026-9127, CVE-2026-9128)
• Studio 5000 Logix Designer V35.01 (CVE-2026-9108)
• Studio 5000 Logix Designer >=V34.00|<=V34.03 (CVE-2026-9108)
• Studio 5000 Logix Designer >=V33.00|<=V33.03 (CVE-2026-9108)
• Studio 5000 Logix Designer >=V32.00|<=V32.04 (CVE-2026-9108, CVE-2026-9127, CVE-2026-9128)
• Studio 5000 Logix Designer V34.00 (CVE-2026-9127)
• Studio 5000 Logix Designer V34.01 (CVE-2026-9127)
• Studio 5000 Logix Designer V33.00 (CVE-2026-9127)
• Studio 5000 Logix Designer V33.02 (CVE-2026-9127)
• Studio 5000 Logix Designer >=V34.00|<=V34.02 (CVE-2026-9128)
• Studio 5000 Logix Designer >=V33.00|<=V33.02 (CVE-2026-9128)

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time. These vulnerabilities have a high attack complexity.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

Opcenter X before V2604 contain an authentication bypass vulnerability that could allow an attacker to gain full unauthorized access to the application. Siemens has released a new version for Opcenter X and recommends to update to the latest version.

The following versions of Siemens Opcenter X are affected:

• Opcenter X vers:intdot/<2604

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany

Vulnerabilities

Acknowledgments

• Siemens ProductCERT reported this vulnerability to CISA.

General Recommendations

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

Additional Resources

For further inquiries on security vulnerabilities in Siemens products and solutions, please contact the Siemens ProductCERT: https://www.siemens.com/cert/advisories

Terms of Use

The use of Siemens Security Advisories is subject to the terms and conditions listed on: https://www.siemens.com/productcert/terms-of-use.

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the exploitation risk of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolate them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most recent version available. Also recognize VPN is only as secure as its connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets. Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

Advisory Conversion Disclaimer

This ICSA is a verbatim republication of Siemens ProductCERT SSA-096828 from a direct conversion of the vendor's Common Security Advisory Framework (CSAF) advisory. This is republished to CISA's website as a means of increasing visibility and is provided "as-is" for informational purposes only. CISA is not responsible for the editorial or technical accuracy of republished advisories and provides no warranties of any kind regarding any information contained within this advisory. Further, CISA does not endorse any commercial product or service. Please contact Siemens ProductCERT directly for any questions regarding this advisory.

Revision History

• Initial Release Date: 2026-07-14

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow for an attacker to cause a denial-of-service condition on the product.

The following versions of Rockwell Automation 1718-AENTR/1719-AENTR are affected:

• 1718/ 1719 Ex I/O 3.011 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow for an attacker to cause a denial-of-service condition on the product.

The following versions of Rockwell Automation 1734 POINT I/O are affected:

• 1734 POINT I/O 3.023 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

The post Teleport enhances Identity Security platform with new AI agent behavior controls appeared first on Help Net Security.

Bub does not look like a traditional video game. Artist and stop-motion animator Case Jernigan spends hours, days, months in his studio drawing, painting and delicately cutting out pieces of collected paper, while coder and gameplay designer Todd Anderson builds scripts and physics simulations to make them into a game.

In Bub, you play through the life of an artist in New York City, making art but also diving into his early memories and imaginative dreams. “You go from present day New York City into his childhood, or different sort of visions, which are all rendered in stop motion,” says Anderson. “His story is told in the present day, but also how he’s making sense of his past.”

ether

This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems.

I frequently find myself reaching for the cut utility when writing scripts to extract one piece of data from a line, or to select specific fields from a log file. While I am familiar with its counterpart, paste , I don't employ it very often because I don't typically need its functionality.

This perhaps has to do with the fact that I rarely work with text files containing lists. For shorter lists, I usually end up using a spreadsheet and for larger ones, a relational database. Both are valuable tools with their own strengths and weaknesses, but it is good to also know about standard utilities for working with lists. After uploading UNIX Curio #8 ( HPR episode 4657 ), I felt like maybe I had been too dismissive of the comm utility in that episode and should talk more about tools that are useful when managing lists.

I don't frequently find myself using paste ¹ , but can explain how it works. Briefly, it is a rough opposite of cut —when given multiple files as arguments, it assembles the first line from each one separated by tabs, then the second line, and so on. Instead of tabs, a different delimiter can be chosen with the -d option. Another option is -s , which swaps rows and columns so that the contents of each named file would appear on one line. While paste itself doesn't qualify as a UNIX Curio in my opinion, there is one feature that does: a hyphen can be given as an argument multiple times. In this special case, the output is taken line by line from standard input, but is spread across as many columns as there are hyphens.

Example of using paste to turn the output of ls into columns. Because these columns are separated by tabs, they don't necessarily line up when a filename is eight or more characters long. The -1 is not required for the second ls command since that behavior is implied when output isn't going to a terminal. The -C option to ls usually gives nicer-looking output on a terminal—also, it lists in ascending order down by column. (Most implementations default to -C when output goes to a terminal.) If you want items ascending along rows like the paste example does, try ls -x instead.

$ ls -1 /proc/net
anycast6
arp
bnep
connector
dev
dev_mcast
dev_snmp6
fib_trie
fib_triestat
hci
icmp
icmp6
if_inet6
igmp
igmp6
ip6_flowlabel
ip6_mr_cache
ip6_mr_vif
ip_mr_cache
ip_mr_vif
ip_tables_matches
ip_tables_names
[...35 more entries not shown...]
$ ls /proc/net | paste - - - -
anycast6        arp     bnep    connector
dev     dev_mcast       dev_snmp6       fib_trie
fib_triestat    hci     icmp    icmp6
if_inet6        igmp    igmp6   ip6_flowlabel
ip6_mr_cache    ip6_mr_vif      ip_mr_cache     ip_mr_vif
ip_tables_matches       ip_tables_names ip_tables_targets       ipv6_route
l2cap   mcfilter        mcfilter6       netfilter
netlink netstat packet  protocols
psched  ptype   raw     raw6
rfcomm  route   rt6_stats       rt_acct
rt_cache        sco     snmp    snmp6
sockstat        sockstat6       softnet_stat    stat
tcp     tcp6    udp     udp6
udplite udplite6        unix    wireless
xfrm_stat
$ ls -C /proc/net
anycast6      if_inet6           l2cap      rfcomm        tcp
arp           igmp               mcfilter   route         tcp6
bnep          igmp6              mcfilter6  rt6_stats     udp
connector     ip6_flowlabel      netfilter  rt_acct       udp6
dev           ip6_mr_cache       netlink    rt_cache      udplite
dev_mcast     ip6_mr_vif         netstat    sco           udplite6
dev_snmp6     ip_mr_cache        packet     snmp          unix
fib_trie      ip_mr_vif          protocols  snmp6         wireless
fib_triestat  ip_tables_matches  psched     sockstat      xfrm_stat
hci           ip_tables_names    ptype      sockstat6
icmp          ip_tables_targets  raw        softnet_stat
icmp6         ipv6_route         raw6       stat
$ ls -x /proc/net
anycast6           arp              bnep               connector     dev
dev_mcast          dev_snmp6        fib_trie           fib_triestat  hci
icmp               icmp6            if_inet6           igmp          igmp6
ip6_flowlabel      ip6_mr_cache     ip6_mr_vif         ip_mr_cache   ip_mr_vif
ip_tables_matches  ip_tables_names  ip_tables_targets  ipv6_route    l2cap
mcfilter           mcfilter6        netfilter          netlink       netstat
packet             protocols        psched             ptype         raw
raw6               rfcomm           route              rt6_stats     rt_acct
rt_cache           sco              snmp               snmp6         sockstat
sockstat6          softnet_stat     stat               tcp           tcp6
udp                udp6             udplite            udplite6      unix
wireless           xfrm_stat

The paste command has limitations—the files you give it must all be already arranged in the same order, and if any file is missing a value, it must have a blank line so that subsequent lines will match up correctly. The files do not necessarily have to be sorted alphabetically, but whatever order they are in has to be the same. Check out HPR episodes 962 and 4201 for some more background on the paste utility.

Example of using paste with files where some values are empty. Bob works from home so doesn't have an office assigned, and the laboratory Carol works in doesn't have a phone. This relies on the fact that the same line number in every file relates to the same person/entry.

$ cat names
Alice
Bob
Carol
Dave
$ cat offices
203

Lab6A
117
$ cat phones
+1 212-555-1234
+1 919-555-2345

+1 212-555-1278
$ paste names offices phones
Alice   203     +1 212-555-1234
Bob             +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278

Our second UNIX Curio for today is a utility called join ² , which has a bit more sophistication. It operates on two files, which can have multiple columns, and combines them using the join field. By default, the first column/field in each file is the join field, and only entries that exist in both files are printed. The -1 and -2 options can be used to join on a different field, and -o selects specific fields to be output. To make it so lines with missing entries also appear, you need to use the -a option, but an actual empty string with separator won't be printed unless -o is also present and includes the field.

The default field separator character is one or more "blanks" in the current locale—for the POSIX locale, this means a space or a horizontal tab. The -t option selects a different character and also removes the treatment of multiple occurrences as a single separator, making it possible to have an empty field in one or both of the files. By default, a single space is used to separate fields in the output. If -t is given, the same character is used for separating fields in both input and output. You would need to pipe output through another tool like tr if you wanted to have a different separator in the output.

The join utility might be an improvement over paste in some cases, since the join field makes it a little easier to identify which entries match up across files. It is limited to operating only on two files (one of which can be standard input), so combining more than that requires either creating temporary intermediate files or chaining together join commands in a pipeline. Another requirement is that all files must already be sorted in the current locale.

Example showing how join can be used with two tab-separated lists. The LC_ALL assignment forces join to sort using the C (POSIX) locale instead of whatever might be set in your environment. The "@" on the header line has no special meaning; it is just there to make sure it sorts before any letters or numbers (in the C locale; it might not in other locales). Note that if -t were not specified, plist would be treated as having three fields because of the space separating the country code from the rest of the phone number.

$ export tab="$(printf '\t')" #To more easily use tab characters below
$ cat olist
@Name   Office
Alice   203
Carol   Lab6A
Dave    117
$ cat plist
@Name   Phone
Alice   +1 212-555-1234
Bob     +1 919-555-2345
Dave    +1 212-555-1278
$ LC_ALL=C join -t "$tab" olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Dave    117     +1 212-555-1278
$ LC_ALL=C join -t "$tab" -a 1 -a 2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob     +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278
$ #By default, join acts as if empty fields don't exist; use -o to include
$ LC_ALL=C join -t "$tab" -a 1 -a 2 -o 0,1.2,2.2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob             +1 919-555-2345
Carol   Lab6A
Dave    117     +1 212-555-1278
$ #The -e option sets a placeholder to use for empty fields
$ LC_ALL=C join -t "$tab" -e "(none)" -a 1 -a 2 -o 0,1.2,2.2 olist plist
@Name   Office  Phone
Alice   203     +1 212-555-1234
Bob     (none)  +1 919-555-2345
Carol   Lab6A   (none)
Dave    117     +1 212-555-1278

The brief description for join is "relational database operator"—I won't dispute that, but in my view it offers far fewer capabilities than people would expect from today's relational databases. I would imagine that when most people think of those they have Structured Query Language (SQL) in mind, which offers a lot more flexibility and functions to operate on data. However, I can see how join could be suitable for simple operations.

Our last UNIX Curio for today relates to the sort utility ³ . While, as you might expect, it is well-known for its ability to sort data, it has another feature that is more obscure. When used with the -m option, instead of sorting the files given as arguments, it merges them together. All of the files are expected to already be sorted—once combined, the list that is output will also be sorted. The order in which the files are named does not matter; it is not required for the contents of the first file to start before the second, just that both are sorted.

$ cat women
Alice
Carol
$ cat men
Bob
Dave
$ sort -m men women
Alice
Bob
Carol
Dave

Imagine that you organize an annual event and have a separate pre-sorted list of attendees' e-mail addresses for each of the past three years. You are planning this year's event and want to send out an announcement to all of these people, as they will probably be interested. The command sort -m -u 2023list 2024list 2025list would spit out a combined list that you can use for your e-mail blast. Because it is likely that some people would have attended in more than one year, I included the -u option—it removes any duplicate entries.

It is probably no surprise that the sort utility appeared early on—it was in 1971's First Edition UNIX, though it didn't gain the merging functionality until Fifth Edition ⁴ in 1973. What did come as a shock to me is that both cut and paste didn't show up until 1980 with System III ⁵ , and were actually preceded by join , which was in Seventh Edition UNIX ⁶ from 1979. I assumed that at least cut would have been around far earlier, given its usefulness and how firmly established it is, but I suppose it just seems to have been with us forever.

As mentioned, I don't typically manage data as text files containing lists, and I probably won't start using the join utility or these features of paste and sort very much. But it is still useful to know that they exist and how they work. Hopefully this episode has taught you a bit about them.

References:

1. Paste specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/paste.html
2. Join specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/join.html
3. Sort specification https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html
4. A Research UNIX Reader: Fifth Edition sort manual page https://archive.org/details/a_research_unix_reader/page/n19/mode/1up
5. System III paste manual page https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man1/paste.1
6. Seventh Edition UNIX join manual page https://man.cat-v.org/unix_7th/1/join

Provide feedback on this episode.

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."

At ESET, cybersecurity isn’t just about reacting to threats, it’s about understanding them, learning from them, and staying ahead of them. For nearly 40 years, we’ve built our expertise on independence, long-term thinking, and deep global insight.

From proprietary technology developed in-house to real-time telemetry that gives us a front-row seat to the world’s most complex cyber challenges, we believe in one principle above all: you can’t protect what you don’t truly understand.

In this video, our founders and experts share what makes ESET different:
• Why independence is critical to cybersecurity integrity
• How we train and use AI responsibly
• What decades of threat intelligence have taught us
• Why trust is built over years not moments
• How we balance innovation with responsibility

We don’t rush decisions. We don’t follow trends blindly. We build solutions that last guided by values that outlast change.

Connect with us on: https://www.eset.com/ https://www.facebook.com/eset https://www.linkedin.com/company/eset/ https://www.instagram.com/eset/ https://x.com/ESET

Der Beitrag reMarkable Paper Pure: Erste Eindrücke zum Nachfolger des reMarkable 2 erschien zuerst auf appgefahren.de.

The post Backpropagation Explained for Beginners (Part 1): Building the Intuition appeared first on Towards Data Science.

The voting process described uses identity verification, authorization checks, machine scanning, voter confirmation, and stored paper records.

Security is not only about preventing digital attacks. Physical processes also rely on layered controls to verify who can participate and preserve records for later review.

What lessons from cybersecurity can be applied to improve trust in physical systems?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#ElectionSecurity #Authentication #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

Read more of this story at Slashdot.

The post One RAG Pipeline, Four Very Different PDFs: Same Four Bricks, Every Answer Typed and Cited appeared first on Towards Data Science.

Visit Mixture of Experts podcast page to get more AI content → https://ibm.biz/~KwWVYq9Sw

Is customizable intelligence the future of AI? This week on Mixture of Experts, Tim Hwang is joined by Aaron Baughman, Chris Hay and Merve Unuvar to analyze Thinking Machines’ first model release, Inkling. Next, Meta makes its comeback with Muse Spark 1.1, positioning itself as the most economical model built for scale. Then, OpenAI’s GPT-5.6 Sol achieves an 8% score on ARC-AGI-3, sparking debate about if we’re approaching AGI. Finally, we dissect Anthropic’s latest paper on the “J-space”—claiming to reveal a subconscious-like layer inside Claude.

All that and more on this week’s Mixture of Experts.

00:00 – Introduction
00:50 – Thinking Machines Inkling model release
19:48 – GPT-5.6 Sol ARC-AGI-3 performance
29:03 – Anthropic’s J-space consciousness debate

The opinions expressed in this podcast are solely those of the participants and do not necessarily reflect the views of IBM or any other organization or entity.

AI news moves fast. Sign up for a monthly newsletter for AI updates from IBM → https://ibm.biz/~x704WfT0B
#claudeai #openai #machinelearning

This one started from setting up the YouTube app on my PS5. The device authorization grant (RFC 8628) it uses, the flow TVs, consoles, and CLIs rely on when they don’t have a browser of their own, turned out to hide two stacked bugs in Google’s implementation.

Two bugs stack together. First, the session that anchors a device-code sign-in is fully transferable: copy the sign-in URL from one browser to another and the second browser’s login satisfies the first device’s poll. Second, the authorization server never binds client_id and scope to the device_code server-side, so both can be swapped in the URL after the fact. Chain the two together with the prompt=none parameter and any link, opened by a victim who has ever used "Sign in with Google" anywhere, silently hands over an access token for an arbitrary Google-registered client, no click, no consent screen, no 2FA prompt, almost no trace in the victim's account activity.

Reported to Google’s VRP on Feb 25, 2026, initially closed twice as “won’t fix”: social engineering, reopened after a one-click PoC, fixed by Mar 28, 2026, and rewarded $13,337. Details on that back-and-forth are in the disclosure timeline below.

1. Intro

Most of the well-known attacks on OAuth go after the client or the resource server: a malicious app, an open redirect, a signing-algorithm mix-up. They leave the authorization server itself alone, because it’s the one party in the protocol that’s supposed to be unshakeable, the thing every other trust decision is anchored to. This is a story about going after that assumption directly, in the one corner of OAuth that’s explicitly designed to let the login happen on a completely different screen: the device authorization grant.

It started as a mundane afternoon setting up a TV app on a game console, and it ended with a way to silently take over accounts on virtually any site that offers “Sign in with Google.” Getting from one to the other took two separate findings stacked on top of each other, a rejected report, and a fix to the fix. What follows is that story, roughly in the order it actually happened, blockers included.

2. The Device Authorization Grant

Most OAuth flows assume the device asking for access has a browser sitting right there to redirect through. RFC 8628 exists for the case where it doesn’t: a smart TV, a games console, a headless CLI. The shape is different from the usual redirect dance:

1. The device calls the authorization server directly (POST /device/code) and gets back a device_code (secret, stays on the device) and a user_code (short, shown on screen).
2. The device displays the user_code and tells the user to go to a URL, google.com/device in Google's case, on any other browser.
3. The user opens that URL on their phone or laptop, types the code, signs in, and consents.
4. Meanwhile the device has been polling POST /token with its device_code. Once the user finishes step 3, the next poll returns an access token.

The whole point of the design is that the device and the browser doing the authenticating can be, and usually are, two completely different pieces of hardware. That’s also exactly what makes this flow interesting to attack: the protocol already expects the login to happen somewhere else. The only thing holding the model together is that the “somewhere else” has to be a browser the legitimate device owner is sitting at.

That’s the assumption. The rest of this write-up is what happened when I went looking for the place where Google’s implementation stops enforcing it.

3. Setting Up YouTube TV on a PS5

I was setting up the YouTube app on my PS5, ordinary first-run setup. The console has no keyboard and no way to type a password comfortably with a controller, so it does the sensible thing: it shows a short user_code on screen and tells you to go sign in on your phone instead. I typed the code into google.com/device, signed into Google, approved the consent screen, and a few seconds later the PS5 was logged in.

Nothing about that felt unusual as a user, but the flow itself was intriguing: a screen with no keyboard asking me to authenticate on a completely separate device, and coming back logged in seconds later. That disconnect between where I typed my password and where the session actually landed is what made me want to look at it more closely. Behind the scenes, that’s:

• POST https://oauth2.googleapis.com/device/code → device_code + user_code.
• The PS5 polling POST https://oauth2.googleapis.com/token with that device_code.
• My phone’s browser walking through https://accounts.google.com/o/oauth2/v2/auth?… to finalize consent once I typed the code and signed in.
• The PS5’s next poll returning an access token.

Standard, boring, RFC-compliant. The interesting part is what that accounts.google.com/o/oauth2/v2/auth URL is actually carrying, and what happens if you don't treat it as disposable. That question is exactly what kicked off everything that follows.

4. The Transferable Session

The obvious question with any flow where “the state lives in a URL” is: what happens if you just move the URL? If the entire sign-in step for a device_code can be handed to someone else, then whoever finishes that sign-in step ends up logged into my device, not theirs.

RFC 8628 §5.4 anticipates exactly this and tells implementers not to let it happen: the whole security model of the flow depends on the user completing verification on a device they’re not about to lose control of.

I started a fresh device flow on the PS5, walked through google.com/device on a laptop, and at the consent screen copied the resulting URL into a second browser. That failed outright: no session for the second browser to pick up.

But the device-code page asks for an email address before showing consent. Entering one forwards the browser to a different endpoint entirely: a challenge page at accounts.google.com/v3/signin/challenge/…, carrying a new parameter, TL=APouJz6T…. Sending that URL to a second browser worked. The second browser prompted a completely normal Google sign-in. Seconds after logging in, that account showed up on the PS5.

TL is an encrypted blob carrying the session state, practically certain to be the device_code, or something that resolves to it, given that it's the only thing left in the URL that could anchor the poll back to a specific device.

Vulnerability #1: the device-code sign-in session is transferable via URL. RFC 8628 explicitly says it shouldn’t be. Send the link, get the account.

That’s a real account takeover, but a narrow one. YouTube TV’s scopes are capped by design, and that cap is the wall I hit next.

5. Breaking the Scope Fence

A YouTube TV account takeover is real, but Google fences the device flow to a short, deliberately low-risk scope allowlist. Per Google’s own docs: “This OAuth 2.0 flow supports a limited set of scopes.” The complete list:

• openid, email, profile
• youtube, youtube.readonly
• drive.appdata, drive.file (app-scoped Drive only, not full Drive)

No Gmail, no full Drive, no cloud-platform, no compute. The access token I got only worked against a YouTube TV–internal API: enough to like a video or subscribe to a channel. Not exactly a headline bug.

So I looked again at the transferable challenge URL:

accounts.google.com/v3/signin/challenge/…
  ?TL=APouJz6T…              <- encrypted session state
  &response_type=none
  &client_id=861556708454-…   <- YouTube TV
  &scope=…                    <- YouTube scopes

Two things stand out. response_type=none means this isn't a normal code/token redirect: there's nothing coming back to a callback at all. And there is no redirect_uri anywhere in the URL. The entire boundary that OAuth normally relies on to pin where a grant goes is simply absent from this endpoint, because the grant never gets delivered through the browser; it gets delivered out-of-band, over the device's /token poll.

The only thing anchoring the session is TL. client_id and scope are just along for the ride in the query string. So: keep TL, swap client_id for a different application, and see which client the authorization server ends up authenticating.

I scripted the device-code issuance, took the resulting URL, and changed client_id from YouTube TV to Google's own Cloud SDK client, with scope changed to cloud-platform, compute, appengine.admin. The consent screen that came back said Google Cloud SDK, listing the elevated scopes. Approving it, my polling script, still polling with the original YouTube TV device_code, got back a token on its next call. Inspecting it: cloud-platform, compute, appengine.admin. Not YouTube.

Vulnerability #2: the server never validates that the client_id and scope in the authorization URL match what the device_code was actually issued for.

Combined with vulnerability #1, the authorization server ends up issuing tokens under one client’s identity (Google Cloud SDK, or any other Google-registered client, first- or third-party) for a session that started under a completely different one (YouTube TV). redirect_uri isn't just weakly validated here: it's not present at all, because the grant never travels through a redirect in this flow to begin with.

The escalation chain worked end to end, at least on paper. Only one step was left: telling Google about it, and finding out whether they’d agree it was a bug at all.

6. From Consent Screen to One Click

I filed this as a report. It came back rejected the next day, citing user interaction: the victim “consented.” Fair, in a narrow sense: the consent screen is genuinely rendered by Google, the click is a genuine click. But the thing being consented to was shaped entirely by parameter substitution in a link I built, and from the victim’s side there is nothing to notice that’s different from any other Google sign-in. Still, “user interaction” was the stated bar, so the next step was removing it.

OAuth has a prompt parameter for exactly the case of skipping the consent screen: set to none, it tells the authorization server not to show any UI if the user has already granted the requested scopes to that client before. It's meant to be narrow, restricted to low-risk scopes like openid, email, profile, and gated on prior consent.

In practice it isn’t narrow at all. “Sign in with Google” is everywhere, and most people have already granted openid email profile to dozens, sometimes hundreds, of apps over the years without ever thinking about it again.

Take the weaponized device-code URL, drop in Facebook’s client_id (any site using "Sign in with Google" works the same way), set scope=openid email profile, add prompt=none. The victim opens the link, and that's the only action required: no consent screen, no button to press. The browser silently completes the flow in the background, the polling script receives an id_token for that third-party application, and that token replays cleanly against the app's own "Sign in with Google" endpoint.

One link. Opening it is the only interaction required. Account takeover on virtually any application that uses Sign in with Google.

The technical bypass was solid. What I didn’t know yet was whether any of it would actually be visible, to the victim or to Google’s own monitoring, if it were used for real.

7. Why the Victim Never Notices

The natural follow-up: surely something surfaces to the victim: a login alert, a new entry under connected apps, a 2FA prompt? It doesn’t, and that’s not incidental. Every signal that would normally catch this gets routed around by the shape of the device-code flow itself.

Audit trail pollution. myaccount.google.com/connections shows the original client bound to the device_code, YouTube TV, never the substituted application. To find any trace of the attack, a victim would have to open the connections page, scroll to find "YouTube TV" among however many connected apps they have, click into it, click "see details" to expand the granted scopes, and then recognize that YouTube TV requesting cloud-platform / compute / appengine.admin is not normal. Five deliberate steps and a piece of domain knowledge very few people have.

Implicit 2FA bypass. The victim goes through a completely ordinary Google sign-in, which already satisfies any 2FA they have configured. The token handoff to the attacker happens afterward, over the device poll, with no further prompt of any kind. The actual high-risk action, an OAuth grant under an arbitrary client’s identity, never trips a high-risk challenge, because as far as the authentication layer is concerned, nothing risky happened; a user just logged in normally.

Stealth, solved. The remaining question was reach: how far the same substitution trick could be pushed past YouTube TV’s own scopes.

8. Extending the Primitive

Stealth is one axis; reach is the other. The same client_id/scope substitution keeps paying out against different corners of the Google ecosystem.

Persistent access via accounts.reauth. Add that scope to the substitution and the resulting grant can refresh indefinitely, with no further victim interaction required: a shoot-and-forget backdoor rather than a one-time token.

A Gmail backdoor via IMAP, not the REST API. Substituting a client_id that's allowed to request https://mail.google.com (Apple's iOS Mail client, for instance) gets a token scoped to full Gmail access. Hitting the Gmail REST API with it fails: "Gmail API has not been used in project 861556708454 before or it is disabled." That project ID belongs to YouTube TV, and the original device-code client never had the Gmail API enabled. That's a project-level gate, not a token-level one, so it's worth checking whether there's another door into the same mailbox. Gmail's IMAP server supports OAuth via the XOAUTH2 SASL mechanism, using the exact same https://mail.google.com/ scope but going through imap.gmail.com:993 instead of the REST API's project-gated surface. It accepts the token without issue. Full inbox access, with the same token the REST API had just rejected.

End to end: a transferable session, plus unvalidated client_id/scope binding, plus prompt=none, equals a link that's invisible to the person who opens it and ends in a fully compromised account, Gmail included.

Chain complete: transferable session, unbound client_id/scope, prompt=none, silent to the victim, and a Gmail backdoor at the end of it. Time to see what Google's VRP panel made of all that.

9. Disclosure Timeline

Feb 25, 2026 Report filed with Google VRP
Mar 2, 2026 Closed: Won’t Fix (Intended Behavior), citing “social engineering”
Mar 2, 2026 Pushed back same day
Mar 3, 2026 Reopened, then closed again: Won’t Fix (Infeasible)
Mar 3, 2026 Countered with a prompt=none one-click PoC against Facebook’s client_id
Mar 4, 2026 Reopened a second time and accepted; bug filed with the product team
Mar 28, 2026 Marked fixed
Apr 2, 2026 Rewarded $13,337

The two rejections both leaned on the same argument: that tricking a user into approving an OAuth prompt is a social-engineering problem, not a vulnerability in Google’s implementation. That didn’t hold up on either pass. The first rejection ignored that this is the exact sign-in flow every Google user already knows, on accounts.google.com, arriving at an app that has no business holding cloud-platform or appengine.admin scopes doing exactly that. The second treated it as equivalent to installing a malicious OAuth app, which the prompt=none PoC against Facebook's client_id directly disproved: there was no prompt to approve, and no app to install; the victim only had to open a link.

10. Mitigations

For a flow that’s explicitly designed to hand sign-in off to a second device, the fix has to happen server-side, since there’s nothing meaningful a client application can check on its own:

1. Keep user_code, device_code, and any session reference that resolves to them out of URLs entirely. If a session can't be copied into a different browser, it can't be handed to a victim.
2. Bind client_id and scope to the device_code at issuance time, server-side. At the consent step, look those values up from that binding instead of trusting whatever the URL says; reject any mismatch.
3. On the consent screen, show device information (name, model) and require the user to actively confirm that device is the one in front of them.

11. Conclusion

The device authorization grant is a narrow, deliberately low-trust flow, right up until the authorization server treats “who is asking” and “what are they asking for” as details that only need to be true at the start of the flow, not checked again by the time consent is granted. Once the session itself turned out to be transferable across browsers, the missing binding between device_code and client_id/scope stopped being a narrow YouTube TV bug and became a way to mint tokens for any Google-registered client, first-party or third-party, capped only by which scopes that client happens to be allowed to request.

Thanks for reading.

Originally published on https://weirdmachine64.github.io/research/google-oauth-device-code-hijacking.html

Confused Deputy: Google IdP Universal Account Takeover via Device Code Flow Hijacking was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Summary

Successful exploitation these vulnerabilities could allow an attacker to execute arbitrary code in the context of the current process.

The following versions of Rockwell Automation Arena are affected:

• Arena <=V17.00.00 (CVE-2026-8085, CVE-2026-8312, CVE-2026-8313, CVE-2026-8314)

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Michael Heinzl reported these vulnerabilities to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of these vulnerabilities.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-16

Legal Notice and Terms of Use

Summary

Multiple SICAM 8 products are affected by multiple vulnerabilities that could lead to denial of service, namely: - SICAM A8000 Device firmware - CPCI85 for CP-8031/CP-8050 - SICORE for CP-8010/CP-8012 - SICAM EGS Device firmware - CPCI85 - SICAM S8000 - SICORE Siemens has released new versions for the affected products and recommends to update to the latest versions.

The following versions of Siemens SICAM 8 are affected:

• CPCI85 Central Processing/Communication vers:intdot/<26.20 (CVE-2026-54798, CVE-2026-54799, CVE-2026-54800, CVE-2026-54801)
• SICORE Base system vers:intdot/<26.20.0 (CVE-2026-54798, CVE-2026-54799, CVE-2026-54800, CVE-2026-54801)

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Energy
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: Germany