USN-8900-1: Go Networking vulnerabilities

Welcome back to PWNED, the weekly column where we highlight some of the lowlights in corporate security. This week, we’ll talk about two scenarios, one that ended in tragedy and another that shows the power of a good defense over dedicated phishing attacks. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Both stories come courtesy of Dave Hatter, a cybersecurity and compliance consultant with Intrust IT. In his many years of experience with the company, Hatter has had to work for a variety of small companies that needed help with their security, whether they knew it or not. One time several years ago, the new CFO at a small construction company phoned Intrust and expressed interest in hiring them. However, the proposal was vetoed by the owner of the company, an older gentleman who thought his business was too small to interest hackers and that his existing, one-person IT staff was all he could afford. “We got a guy, my brother’s uncle’s cousin does my IT, don’t need you guys,” Hatter quotes the owner as saying. “We hear this all the time. Thanks for shopping. You’re too expensive.” Three weeks later, Hatter got a call from a local accountant friend who begged him to help a client who'd been hit with a ransomware attack. Hatter said he couldn’t really give more than general guidance, but would talk to the victim anyway. As soon as he called the number, Hatter realized that the ransomware victim was actually the same construction company that had turned down his services a few weeks earlier. The business had an old unpatched Windows server that contained all its most important data. There was a backup drive, but it was connected to the same server, so both devices were encrypted by the ransomware. “Their entire backup is this external drive, which, of course, is now encrypted,” Hatter said. “So, literally, they can't pay their employees. They don't know who owes them money.” Hatter could not help the company, and he never found out whether it paid the ransom. However, the org, which had been around for years, went out of business within months. This sad story shows the importance of having real backups that are off-site or in the cloud and patching whatever servers you have. You can never assume that your company is too small to be attacked because ransomware gangs want your money and they are just as happy to take on small businesses as large ones, which are likely to be harder targets. The other incident involved two companies in the landscaping and construction business. Somebody broke into an executive’s email account at company one and started sending phishing emails to company number two. The miscreants had also set up email filtering rules in the first company’s account so that the messages from the phishing campaign were routed to buried folders where the real-life account holder would never see them. The phishing mails took the form of RFPs (requests for proposal) – a perfect lure, because who wouldn't want new business? They were perfectly crafted, with no grammar errors or obvious tells, and the return address matched company one's. However, instead of attaching the RFP as a PDF or PowerPoint file, it had a button for the user to click to download it. “If I can get in your email and send out emails as you, the recipients, especially if they've interacted with me before, aren't going to have any guard up,” Hatter said. “Especially if there's no crazy language or crazy requests in there because they've got an email from me before.” Upon clicking the download button, the user was transported to a Microsoft 365 login screen that looked identical to the real one but was not on the microsoft.com domain. The user was then invited to put in their email address and password to gain access to the desired file. Because the user had 2FA, this fake page also asked them for their limited-time 2FA code. Behind the scenes, the threat actors were transmitting the login to Microsoft so that Microsoft itself would send an SMS message to the victim at company number two. Then the victim would pass along the one-time passcode via the fake login site. A classic man-in-the-middle attack. It worked, and the threat actors now had access to the Microsoft 365 account and email for the victim at company number two. This could've allowed them to do almost anything using that person’s email. If the victim had access to bank accounts or customer data, the attackers could have initiated password resets from the account, then conducted fraudulent money transfers, or stolen personal information. At the very least, they could've used the victim's account to phish other contacts. Fortunately, Hatter's client had installed a piece of software his company made called TarBot, which runs in the Microsoft 365 environment and uses Entra ID P2 to help customers identify suspicious logins. “It throws off a bunch of telemetry, statistics, metrics, whatever you want to call it, that allows our software to say, this is an anomalous login, revoke the token, and make the user log in again,” Hatter said. He said his company is not the only one to make apps like TarBot that detect suspicious logins. So the bad guys were kicked out after just a few minutes. But Hatter says the better way to stop these attacks is to use phishing-resistant MFA, such as hardware keys (like the YubiKey line) or passkeys. With today’s AI-assisted phishing, telltale signs such as bad grammar or obviously fake login pages are becoming few and far between. ®

The FortiBleed credential-harvesting and access-broker campaign is still active, and attackers are locking organizations out of their Fortinet devices. Targeting internet-accessible Fortinet FortiGate firewalls and SSL VPN appliances, the campaign started in June. Fortinet’s analysis of the attacks revealed that the attackers were using previously compromised credentials and brute-force techniques to take over poorly protected devices. Within a week, the attacks hit over 86,000 Fortinet devices in 190 countries, and a Russian initial access broker was blamed for the campaign. Now, SOCRadar says it has confirmed the compromise of approximately 86,644 devices in 194 countries. The attackers are searching for accessible firewalls and using compromised credentials to take them over. “[This] is a count of confirmed-compromised devices, not an exposure estimate. Devices breached months ago remain in the actors’ validated inventory,” SOCRadar notes. In a joint advisory (PDF) released this week, the FBI and the US Secret Service (USSS) warn that the hackers have been locking organizations out of their Fortinet appliances by changing passwords and deleting accounts. “Some victims may get locked out of their Fortinet devices if the threat actor either deletes or changes the password for original accounts on the system. In certain cases, threat actors delete existing accounts to block organizations from accessing affected devices and to maintain persistence on the system while attempting lateral movement within the environment,” the advisory reads. The hackers have been observed scanning for exposed SSL VPN portals, harvesting credentials from infostealer logs and previous dumps, cracking hashed credentials offline, mapping the attack surface to evade honeypots, using verified credentials to compromise devices, and selling working VPN configs and target lists to other threat actors. The FBI and USSS recommend that affected organizations identify the compromised hosts, scope the intrusion, evict the attackers, harden protections to prevent additional threat actor activity, and report the intrusions. To reduce the attack surface, organizations should restrict management access, reset all Fortinet VPN and administrative passwords, implement phishing-resistant multifactor authentication (MFA), review firewall and VPN users and configurations, review and validate API keys, review logs for suspicious activity, and ensure credentials are stored securely. Related: Long-Running NPM Malware Campaign Accumulates 40,000 Downloads Related: Anthropic Introduces 3-Tier Cyber Verification Program for AI Access Related: Wikimedia Says Rogue OpenAI Agents Tried to Turn Its Tools Into Proxies Related: FBI Blames Contractor’s Missed Patch for ShinyHunters Breach

Pricing your bad days and how to build an economic model for security decisions Ivan Milenkovic, VP Risk Technology EMEA at Qualys, explains how security leaders can build an economic model that puts money behind their decisions. He suggests starting with a few loss scenarios, then working down to the assets that drive them. He covers how to rank fixes by value at risk, what CFOs expect to see, and how to show the worth of incidents that never happened. He also looks at how one model can serve both the board and cyber insurance underwriters. Most security teams can tell a board how many vulnerabilities they closed last quarter, but very few can say what that work was worth in money. When a CISO sits down to build an economic model for the first time, where do they usually go wrong? An economic model exists to support a decision about value. Most security models I’ve seen never get that far. They start with a score and end with it: is this OK, and should we fix the red ones first? We congratulate ourselves on the effort, and the board learns nothing about what the effort was worth. Credit is a useful comparison. A lender’s score sits on top of a question about money: what’s the chance this borrower won’t repay this amount, or won’t repay on time? There’s plenty of clever modelling around that question, but at its heart is a value function. The maths is principled, and the score means something because it’s anchored to a potential loss. Most security scoring has no such anchor. We’ve spent years measuring how complex the technology is and how hard it is to keep up, but we’ve spent very little time costing what those issues do to the business over time. That’s where first-time models go wrong: they start with ten thousand findings and try to work their way up to money. I suggest CISOs reverse the order, and name the handful of scenarios that would genuinely hurt: the payment platform down for three days, a regulator’s letter about customer data, ransomware across a region, or whatever is applicable to your organisation. Put a loss range on each of these scenarios, then work down to the assets and exposures that drive those losses. The first version will be wrong. Early credit models were wrong too, and they improved because people kept feeding them real outcomes. Yours will improve the same way, provided the inputs come straight from the systems. My rule from my CISO years still applies: if the number has been touched by a human, I don’t believe it. With thousands of findings competing for attention, deciding what to fix first becomes political. How should an economic model adjudicate between a severe flaw on a low-value asset and a moderate one sitting on a revenue system? It turns political because the evidence on the table is technical, and technical arguments rarely settle a budget fight. Every security team has known situations around what was “right” to do, and lacked the budget or people to do it. When that happens, it’s tempting to blame the business for not listening. The better question is, what did we give the board to decide with, and why did it not convince them? The model should adjudicate on value at risk, or more simply, what do you stand to lose? How much would this particular exposure add to plausible future loss? A severe flaw on a test server nobody uses adds almost nothing. A moderate flaw on an internet-facing revenue system can add a lot, especially if attackers are already exploiting it. I once worked with a business unit ranked the worst in its group for exactly this reason. A pile of servers disconnected from revenue, heavy with CVEs, was scored the same as the payment gateway, and the team was spending its hours patching the wrong machines. The maths for modelling all this exists, although it runs on forecasts. What you need is a lightweight model that gives a fast, defensible view of two things: the potential loss from a risk, and the upside of acting on it, including what the fix enables commercially. A CEO uses that kind of information for every other decision in the company. It’s also worth looking at how much detail you provide. Asset-level and vulnerability-level context has to feed the model, because that’s where the test server gets separated from the payment gateway in terms of priority and business impact. The board shouldn’t be arguing about individual CVEs, though. Their question is whether our controls are scaling across the enterprise relative to what we stand to lose. That question is getting harder to answer due to the effect that AI has had on vulnerability discovery. One frontier model alone surfaced more than 6,000 candidate high- or critical-severity flaws across over 1,000 open-source projects. Nobody fixes all of that. The response now is to say which issues matter, and to put a signature next to the issues you’ve judged to leave. You are constantly proving the value of incidents that never occurred. How do you make “nothing went wrong” legible as a return that a finance team will respect? The CFO does this all day: they own insurance and capital reserves, and they plan for bad days. Cyber losses are only one kind of loss they have to consider. Their question around any risk is simple: given our exposure, could a loss overrun our limits and hit the cash we have on hand? Insurance and treasury use the same kind of modelling to set limits and reserves, and the actuaries behind your broker are already running it on your IT organisation as well. The difference is that they know less about your residual cyber risk than you do. From a financial perspective, your job is to buy down plausible future loss using your team, your security controls and your investments until the chance of breaching those financial backstops sits inside the limits the business has set. “Nothing happened” will never stand as evidence on its own, and it shouldn’t. You aren’t doing nothing either, so those controls should be – pardon the pun – accounted for. Finance respects measurable change, so report what moved: How long critical exposure survived on the systems behind your loss scenarios, this quarter against last. How much plausible loss sits in exposures that are past their remediation deadline. Whether controls held when tested: for example a restore that worked, or a red-team exercise stopped at a segmentation boundary. What the market thinks. Underwriters now price on cyber controls in finer detail, so better terms at renewal are an outside valuation of your programme. None of these signals is perfect on its own. What you should look at is performance over time, so your signals need to be consistent, sourced from systems, and refined every quarter, the same way finance refines its own forecasts. That’s how security earns a seat in the conversations where money gets allocated. What does a CFO want from a security leader that the security leader almost always forgets to bring? CFOs want a number they can put in a spreadsheet, with a range around it, and a decision attached. Security leaders talk in security words: vulnerabilities, threats, mean time to respond, and so on. Underneath that vocabulary sits a binary, where something is either secure or it isn’t. The CFO works in money, percentages and likelihoods, where very little is black and white, and that gap frustrates a lot of CISOs. It helps to remember that we aren’t the only risk experts in the building. The CFO, the CRO and the treasurer have been pricing uncertainty for their entire careers, so learn their language and bring it with you. Boards and CFOs are far more tech-literate than they were ten years ago, but translation is still your job. In practice, bring four things to every CFO conversation: The loss scenario, in money, as a range. How likely the loss is over the next twelve months, and what that estimate rests on. What you propose to spend, and how far the range moves if you spend it. What happens if you don’t, including who has to sign for leaving that issue as it is. The last one is what CISOs forget most often. A CFO can’t approve or reject a risk that nobody owns. Once the person whose budget absorbs the loss has to sign the acceptance, the conversation changes quickly. You can track those scenarios quarter by quarter, so the CFO can see the trend. Cyber insurance underwriting and risk quantification are converging on the same questions. Does a model that satisfies the board also satisfy an underwriter, or are you preparing two different stories? You might have one model, but you have to report to two audiences. If the board hears one story and the underwriter another, you have a bigger problem than presentation. Anything you tell an underwriter has to hold up on the day you make a claim. What changes is what each audience sees: boards don’t need to sit through cyber risk quantification discussions, they need information to make decisions or understand why a decision was made based on that financial information. They’re usually pre-socialised to capital decisions before you walk into the room, so your job is to bring a grounded rationale for what you decided. Underwriters want the evidence underneath: control maturity, exposure windows, how fast you expect to recover. Carriers are underwriting more granularly on controls, privacy exposure and emerging AI risk, so the same data that drives your model should go into your submission. Here’s what a board update might sound like: “Frontier AI models are finding vulnerabilities at a scale we haven’t seen before, and our backlog grew 200% in Q2. We’re investing in AI-assisted remediation and expect to be back to pre-Mythos levels by the end of next quarter. We’ve reviewed our limits with risk management under the CFO, and we’re meeting our brokers next month to increase them. The timing helps: the market is soft, so we expect to add cover for a modest premium increase.” Look at what’s in there: a cause, a number, a decision, a date, and a link to the CFO’s own instruments. The timing point deserves attention. UK cyber pricing stayed soft through Q2 2026, with better terms for buyers who can evidence strong controls. Specialist underwriters are already warning of an inflection point this year. The organisations with an honest model will get the best terms while they last.

The npm package known as "tensorlake," a TypeScript software development kit (SDK) for Tensorlake applications, sandboxes, and cloud services, was compromised as part of a ChainDrop / Shai-Hulud supply chain attack. The malicious version 0.5.144 "contains obfuscated malware that harvests credentials, exfiltrates secrets, establishes persistence, and executes remotely supplied code," Socket said. Version 0.5.144 is no longer available for download from the npm package registry. An analysis of the compromised release shows that it contains a preinstall hook designed to launch a JavaScript file ("package/lib/setup.mjs"), an obfuscated loader that launches the main credential-stealing and self-propagating worm ("package/lib/Math_Symbol.js") using the Bun runtime. The stealer malware is designed to harvest credentials across local files, CI environments, Kubernetes, and Vault sources. It also drops the HackBrowserData binary, exfiltrates the collected data, establishes persistence on the host, and facilitates the execution of remotely-supplied code. "That combination extends the risk beyond a single stolen API key," Socket said. "Any secrets accessible to the executing process may be exposed, and persistence can retain attacker access after the affected dependency is removed." The types of data stolen by the malware are below - npm tokens GitHub tokens Amazon Web Services (AWS) credentials and secrets HashiCorp Vault Kubernetes credentials SSH keys .env files Cryptocurrency wallets Messaging app data Configuration and MCP files associated with Anthropic Claude, Cursor, Kiro, Windsurf, and Zed "To propagate, the worm enumerates packages associated with the victim's publishing identity, builds Sigstore provenance, and republishes compromised versions," Socket explained. "Strings referencing a fake Copilot/Dependabot workflow suggest it also plants GitHub Actions workflows." The malware also makes use of an Ethereum contract to resolve its command-and-control (C2) endpoint ("iseekaigogo[.]com"), with GitHub acting as a fallback mechanism to stage the encrypted stolen data in a public repository with the description "Shai-Hulud: Here We Go Again." In addition, there exists a "hostage token" component that uses a PowerShell monitor to repeatedly poll "api.github.com/user" using the stolen GitHub token to check if the token is valid. Should the victim take steps to revoke the token, the monitor proceeds to execute an attacker-supplied handler through the "Invoke-Expression" cmdlet to execute PowerShell code designed to likely trigger a destructive routine – a tactic observed in earlier Shai-Hulud waves. According to StepSecurity, the malicious files were pushed to the main branch of tensorlakeai/tensorlake under a maintainer's name, after which the package was released from that same repository. The first rogue commit took place on October 7, 2026, at 01:20 a.m. UTC. A day later, the repository's release workflow published 0.5.144 to npm. "The malware also writes .claude/settings.json and .vscode/tasks.json files into repos it can reach, so it runs again when someone opens the project in Claude Code or VS Code," StepSecurity's Ashish Kurmi said. ChainDrop was first documented in early August 2026 in connection with the compromise of hundreds of npm packages, including Keyv and Cacheable, that were found to contain a Mini Shai-Hulud variant with a self-propagating credential-stealing worm delivered through an obfuscated Bun-based JavaScript payload. The development extends the supply chain attack to artificial intelligence (AI) agent infrastructure, once again highlighting how threat actors are increasingly targeting AI tools and services to extract valuable data from enterprises. Users who have installed the malicious version are advised to remove it immediately and rotate their credentials.

How AI can fix cybersecurity compliance: From dashboards to continuous execution Most compliance work goes into proving security, not improving it. That isn’t because the rules are unreasonable. Regulators, customers, and cyber insurers are right to expect organizations to implement hundreds of technical and administrative controls, monitor their environments, respond to incidents, and prove that all of it works. The problem is the cost of delivering it. The Pentagon’s own estimate puts a small contractor’s CMMC level 2 compliance at roughly $105,000 over three years. That figure covers only assessing and attesting to compliance, not implementing a single control. In our experience working with small and midsize businesses, the full first-year cost of a compliance program runs from $50,000 to well over $300,000, depending on the framework, the organization’s starting maturity, and how much outside consulting it needs. The strain is showing. In July, the Department of War suspended Phase 2 of CMMC (Cybersecurity Maturity Model Certification), which would have required third-party assessments for contractors handling controlled unclassified information. It launched a 60-day review with an eye toward easing the burden on small and midsize businesses. Yet the underlying obligations didn’t go away. Contractors working with DoW must still meet compliance standards and submit self-assessment scores. The same burden applies across SOC 2, ISO 27001, HIPAA, HITRUST, FINRA, and NYDFS: implement the controls, keep them running, and prove it. An assembly line that never stops Compliance isn’t a checklist. It’s an assembly line. It starts with policies, asset inventories, and risk assessments. Next come control implementation and employee training. Then the daily grind: monitoring, patching, vulnerability management, incident response, and remediation. Every step must be documented and every control backed by evidence, while systems, users, and regulations keep changing. The day one audit closes, prep for the next one begins. To keep that line moving, a typical organization stitches together more than 20 tools. These span identity management and MFA, endpoint protection (EDR), device management (MDM), firewalls, SIEM, backup, encryption or CMMC enclaves, vulnerability scanning, and many more. On top of the tools come an MSP, a SOC provider, consultants, auditors, and someone to coordinate it all. Controls get applied unevenly, and documentation goes stale. Weeks before the audit, everyone scrambles to reconstruct evidence for controls that may have been working all year. The irony is that most of this effort doesn’t make anyone more secure. It goes into proving security that already exists. Traditional compliance software didn’t fix it The first generation of GRC platforms replaced spreadsheets with dashboards. They centralized policies, mapped controls to frameworks, assigned tasks, and sometimes pulled evidence automatically from cloud services. That was real progress. But it left the hardest part untouched. Somebody still has to deploy endpoint protection, configure MFA, patch systems, encrypt devices, triage alerts, and fix what’s broken. A dashboard can tell you a control exists. It can’t enforce it. Attackers already run at machine speed There’s a second reason manual compliance can’t keep up: the adversary has automated. A CISO I know recently walked me through a breach at his company. The attackers got in and left with the data in seven minutes. No ticket queue, on-call rotation, or morning triage meeting moves that fast. Seven minutes sounds extreme, but the numbers are heading the same way. CrowdStrike reports that the average time for a criminal intruder to move from initial access to other systems fell to 29 minutes in 2025, and the fastest took 27 seconds. Operations by AI-enabled adversaries rose 89 percent. AI is also putting these capabilities in the hands of amateurs. Earlier this year, Amazon’s threat intelligence team found that a single, modestly skilled criminal had used commercial AI tools to break into more than 600 firewalls across 55 countries in about five weeks. Now compare that with how most compliance programs operate: a quarterly access review, a monthly patch window, an alert that sits in a queue over the weekend. A control checked once a quarter won’t stop an attacker who needs seven minutes. When offense runs at machine speed, defense has to as well. That means catching drift the moment it appears, closing the gap automatically, and bringing in a human for the calls that need judgment. The Amazon case holds the most important lesson. The attacker didn’t use a single zero-day. They got in through exposed management ports and passwords without MFA, the same basics every compliance framework already requires. When they ran into hardened environments, they simply moved on to easier targets. Controls that are actually enforced, every day, are what make an organization the harder target. The automation that satisfies the auditor is the same automation that sends attackers looking elsewhere. From compliance dashboards to continuous execution AI-native compliance platforms flip that model. Instead of telling teams what to do, they do the work. Take a control like “ensure unauthorized applications are not used.” A dashboard displays it as a task. An operational platform scans endpoints, detects unapproved software, prioritizes the risk, and removes or quarantines the software according to policy. It logs each action as audit evidence along the way. The same approach applies across the whole lifecycle. The platform drafts policies tailored to the environment and maps one set of controls to CMMC, SOC 2, ISO 27001, and HIPAA at once. It watches endpoints, identities, cloud services, and networks for drift. It investigates alerts around the clock and opens remediation tickets. As a result, evidence becomes a byproduct of daily operations rather than a separate project. Audit prep shrinks dramatically. Instead of a snapshot once a year, organizations can see their real security posture every day. People still make the calls None of this removes the need for security professionals. It changes where they spend their time. AI handles the repetitive work: monitoring, evidence collection, documentation, and routine remediation. Humans own architecture, governance, serious incidents, and decisions about which risks to accept. And a human remains accountable to the auditor for everything the system does. For most SMBs, this is the only realistic path to a mature program. They could never afford to hire the IT, security, compliance, and SOC staff needed to do it all manually. Pairing AI-driven execution with expert oversight lets them raise the bar without growing headcount at the same pace. This is the future The next evolution of compliance platforms is an intelligent, operational layer that drafts policies, implements controls, monitors the environment, assists with remediation, and continuously collects evidence as work happens. The first generation of compliance software helped organizations document security. The next generation will help them operate it. Organizations that embrace this shift won’t simply spend less time preparing for audits. They’ll spend less time managing compliance and more time improving their security, serving their customers, and growing their business.

Java library vulnerabilities: IBM and Red Hat fix 400+ previously unknown flaws IBM and Red Hat have found and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries through Lightwell, their program for patching open source code that companies already run in production. Companies running the affected libraries are exposed until they apply the fixes. Autonomous AI agents can now combine several minor software weaknesses into one serious attack. “AI agents do not care if a codebase is ten years old or otherwise considered stable, because one small crack is all it takes to chain an attack together. Finding those bugs is only half the battle: the real work is backporting fixes directly into active production apps so customers do not have to pick between security and uptime. Finding and neutralizing 400+ novel vulnerabilities so quickly shows how fast Lightwell can move, and we are just getting started,” said Gunnar Hellekson, VP and GM, Lightwell, Red Hat. The two companies also made Lightwell Clearinghouse generally available, letting enterprise customers submit specific open source dependencies for priority review and repair. How the fixes reach customers Lightwell backports the patches. That means it rewrites each fix to fit the older library version a company still runs, so the team can apply it without first upgrading. The patches arrive through secured repositories that plug into a customer’s existing scanners, software repositories, development pipelines and testing. Clearinghouse adds a request line: a customer names a vulnerability it cares about, and Lightwell reviews it, fixes it and supplies a patch for the older version in use. No names, no CVEs, no severity scores The companies didn’t say which libraries were affected. You won’t find CVE numbers, severity ratings or a time frame for the 400 finds either. Red Hat says fixes that apply upstream go back to the open source projects through responsible disclosure, though Clearinghouse participants keep their embargo protections. So if you use these libraries and you’re not in the program, your fix will come from the public upstream release, whenever disclosure allows it. Webinar: Closing the accountability gap in AI-assisted delivery

Medical devices patients rely on most are least prepared for quantum attacks Threat actors are exploiting IT, IoMT, OT and IoT devices across healthcare delivery organizations (HDOs) to deploy ransomware, demand payments and monetize stolen patient data, according to Forescout’s Post-Quantum Cryptography (PQC) in Healthcare: From Data Risk to Migration Readiness report. Researchers analyzed a dataset containing more than 2.5 million devices across more than 50 HDO networks. Separately, between January and August 2026, they tracked 461 public ransomware claims and 300 hacktivist attack claims against healthcare providers worldwide. “Unlike many other types of data, patient information retains its value and sensitivity for decades, making it particularly vulnerable to harvest-now, decrypt-later attacks. In these attacks, adversaries collect encrypted data today with the intent of decrypting it once sufficiently powerful quantum computers are available. Medical histories, diagnostic images, laboratory results, prescription records, and other healthcare data cannot simply be reset or replaced if exposed. Organizations need to understand where this data resides, how it moves across their environments, and which systems will be most difficult to transition to PQC standards,” said Daniel Trivellato, VP of OT, Healthcare, and Cyber Risk Solutions at Forescout. Equipment upgrades depend on vendors Across enterprise networks, only 6% of connected medical devices and 16% of operational technology devices used SSH software capable of supporting PQC, compared with 50% of IT devices. SSH provides secure remote access for managing equipment. These figures show that the software can support quantum-resistant protection, they do not establish whether that protection is in use. Hospitals rely on infusion pumps, ventilators, patient monitors and building controls that can remain in service for years. Updating their cryptography may depend on vendor release cycles, recertification or hardware replacement. These dependencies can delay migration and complicate upgrade schedules. Migration planning should establish which systems can be upgraded and when vendors will provide support. Equipment that cannot be updated may need to be isolated or replaced, with changes coordinated to maintain patient care. “Healthcare providers need to understand which assets store, process, and transport their most sensitive data, which systems can realistically be upgraded, and where compensating controls will be required. Our research shows that the devices least prepared for the transition are often the same devices healthcare organizations depend on most for delivering patient care. Visibility into those assets and the data they handle is essential for building a practical migration strategy,” said Daniel dos Santos, VP of Research at Forescout. Patient information crosses network boundaries Migration priorities depend on the information each system handles and how long it requires protection. Patient records and diagnostic images can remain sensitive for decades. Appointment schedules and live readings from patient monitors also have requirements for privacy, accuracy and availability. Security teams need to map where this information is created, stored and transmitted, including its passage through servers, routers and remote access gateways. This mapping helps identify data vulnerable to harvest-now, decrypt-later attacks and prioritize upgrades. Connections between medical equipment and other systems can expose patient information. A CT scanner, for example, sends images to a picture archiving and communication system (PACS) that may be accessible over the internet. Exposed systems can provide a path for attackers to access sensitive imaging data. Researchers found more than 5,500 instances of medical information systems exposed online. Electronic medical record platforms accounted for 46%, and PACS accounted for 40%. The researchers also identified laboratory management and medication dispensing systems. Across the exposed system types, the average share supporting TLS 1.3 was 31%. This protocol version provides a foundation for standardized PQC in network connections. Assessing migration readiness also requires checking whether quantum-resistant protection has been deployed.

Unit 42 details how threat actors leverage Web3 infrastructure and open-source supply chain attacks to breach enterprise cloud environments The post Evolution of Web3 in Cloud Supply Chain Attacks appeared first on Unit 42 .

This post shows you how to configure an AI model to perform structured, evidence-based vulnerability triage with the consistency of a seasoned security analyst. You’ll learn the design decisions behind five configuration sections that enforce structural verification, evidence-based scoring, and infrastructure-aware prioritization across every analysis session. Our companion post— Building your AI vulnerability harness —covered the architecture; this post covers the configuration. The distinction matters because the same frontier model that produces a rigorous, evidence-grounded security assessment with one set of instructions will produce hallucinated attack chains and inflated severity ratings with another. The model’s capability is fixed. What you configure is its judgment. We learned this the hard way while building the harness. Our early iterations produced findings that sounded authoritative but crumbled under scrutiny. The model would report a SQL injection in a function that didn’t exist, claim HIGH confidence based on nothing structural, or ignore an AWS WAF in blocking mode directly in the request path. The output wouldn’t have earned engineering trust in that state. The fix wasn’t a better model. It was better steering. What a steering file is A steering file is a set of instructions that an AI coding assistant loads at the start of every session. Different tools use different conventions—Kiro reads markdown files from a .kiro/steering/ directory, Claude Code uses CLAUDE.md , Cursor uses .cursorrules , and GitHub Copilot uses .github/copilot-instructions.md —but the function is the same: persistent instructions that shape how the model approaches work in your repository. Applied to security analysis, a steering file encodes your team’s triage methodology as machine-executable instructions. Instead of relying on individual engineers to apply that methodology consistently, you encode it once and the model applies it uniformly across analyses. The steering file we’re releasing encodes the architectural principles from the harness post as operational instructions. Where the harness post says apply infrastructure-aware assessment , the steering file specifies exactly how: which controls map to which multipliers, how multipliers stack, and what floor prevents over-confidence in any single control. Why configuration outperforms prompting A single-turn prompt ( find vulnerabilities in this code ) produces whatever the model’s default behavior generates. That default is optimized for helpfulness, not rigor. The model will find things to report because you asked it to find things. A steering file changes the default. It establishes: What counts as evidence: Without explicit instructions, a model treats its own reasoning as sufficient evidence. The steering file requires structural verification—confirmed dataflow, confirmed function existence, and confirmed call path—before a finding is reported. What confidence means: On its own, a model assigns confidence based on how plausible its narrative sounds to itself. The steering file replaces self-reported confidence with a formula computed from binary structural signals. Either taint analysis confirms the flow or it doesn’t. Either a call graph connects entry point to sink or it doesn’t. How infrastructure affects priority: Left to its defaults, a model assesses vulnerabilities in isolation from their deployment context. The steering file requires parsing infrastructure as code (IaC) and applying control-specific multipliers before assigning priority. The goal is reproducibility: the same codebase should produce the same assessed findings regardless of who runs the analysis or when. Consistency is the point. The five sections that matter The full steering file is available in the companion repository. In this section, we explain the design decisions behind its five critical sections. Structural verification over LLM trust Never trust an LLM's self-reported confidence about a vulnerability. Verify claims against the code structure: 1. Do referenced files exist? 2. Do referenced functions exist? 3. Does dataflow confirm the claim? 4. Is there a call path? If a finding fails all structural checks, reject it regardless of how convincing the narrative sounds. This is the single most important instruction in the file. Without it, the model generates plausible-sounding attack chains that reference functions that were renamed three commits ago, files that exist in a different package, or dataflows that pass through sanitization that the model failed to notice. We found that approximately 30% of unsteered model findings referenced code structures that didn’t exist in the target repository. Not wrong interpretations—entirely fabricated paths. The instruction to verify before reporting produced zero fabricated paths in our testing. The key insight: hallucination in security analysis isn’t a minor annoyance. One hallucinated finding that reaches a developer destroys the can quickly erode the credibility of your entire pipeline. Engineers who encounter a fabricated vulnerability are less likely to keep reading the reports. Evidence-based confidence scoring The following formula replaces the model’s intuitive confidence with a score computed from observable signals. Each factor is binary: confirmed or not confirmed. confidence = 0.30 * taint_confirms_flow + 0.25 * no_sanitization_found + 0.20 * entry_point_is_public + 0.15 * call_graph_confirms_path + 0.10 * sink_type_matches_category We weighted taint confirmation highest (0.30) because a confirmed dataflow path—evidence that user-controlled data reaches a security-sensitive operation—is the single strongest predictor that a finding is real. In our validation against known-vulnerable applications, findings with confirmed taint and no sanitization were exploitable 89% of the time. Findings where the model reported HIGH confidence without structural confirmation were exploitable 34% of the time. The formula is a starting point, not a fixed standard. Your weights should reflect your own validation data. Run the formula against a labeled dataset of known true and false positives, then adjust until precision matches your team’s tolerance for noise. Infrastructure-aware assessment This section addresses a common category of over-prioritization: reporting a vulnerability at full severity when compensating controls are already in place. score_after_controls = max(0.15, score * block_1 * block_2 * ... * block_n) Controls are mapped to specific vulnerability classes. An AWS WAF with SQL injection rules in blocking mode is a STRONG control (0.25x multiplier) against SQL injection. It is irrelevant to deserialization attacks. The steering file specifies this mapping explicitly rather than leaving the model to guess. The multiplicative stacking of attack-blocking controls with a floor of 0.15 encodes defense-in-depth thinking. Multiple controls reduce risk more than any single control, but no combination of controls reduces risk to zero. The floor prevents the model from concluding that a vulnerability is completely mitigated and can be ignored. A subtlety we learned through validation: access controls (authentication and authorization) and attack-blocking controls (AWS WAF rules and input validation) serve different functions. Authentication limits who can attempt an exploit. It doesn’t limit what happens when an authenticated user attempts one. A command injection behind AWS Identity and Access Management (IAM) authentication is still a command injection; the attacker pool is smaller, but the impact when exploited is unchanged. The steering file accounts for this by mapping control types to specific score components rather than applying a blanket multiplier. Threat intelligence integration The steering file incorporates signals from the CISA Known Exploited Vulnerabilities (KEV) catalog and the Exploit Prediction Scoring System (EPSS) to boost priority when threat intelligence indicates active risk. The following table lists the primary signals the steering file recognizes and the boost that each signal adds to a finding’s score. Each signal answers a different question about real-world exploitation risk: CISA KEV – Indicates that attackers have exploited the vulnerability in the wild and notes whether it is tied to ransomware campaigns. EPSS – Estimates the probability that attackers will exploit a vulnerability in the next 30 days. Public proof of concept (PoC) – Indicates that working exploit code is already published, so an attacker has little work left to do. Signal Boost Actively exploited (CISA KEV) +0.30 Ransomware-associated (CISA KEV) +0.15 EPSS >= 0.5 +0.20 Public PoC exists +0.10 There’s a cap at +0.50 total boost to prevent threat intelligence from dominating the score. A vulnerability isn’t more technically exploitable because attackers are targeting it, but it is more urgent because the window between theoretically exploitable and actively exploited can be very short. We separate urgency from severity deliberately. A medium-severity dependency vulnerability under active exploitation by ransomware groups demands a faster response than a critical-severity code-level finding that requires complex preconditions and has no known tooling. Priority classification Scoring produces a number and priority classification turns that number into a decision, which is what a developer on the receiving end of a finding needs. The following table shows the four action tiers that the steering file defines. The score and evidence thresholds determine which tier a finding falls into, and each tier prescribes a specific response. The steering file compares these thresholds against the final score: the base score after it applies attack-blocking multipliers and any threat-intelligence boost. That final score is not the confidence value from the formula earlier in this post, and it is not the severity that the scanner reported. Priority Criteria Action P0 Score >= 0.8, no effective attack-blocking mitigation Fix immediately P1 Score >= 0.6 OR active threat intel Fix this sprint P2 Score >= 0.4, partial evidence Investigate when capacity P3 Score < 0.4 or effectively mitigated Accept risk or backlog The most controversial instruction in the file: Do not file P3 findings as security issues. We include it because filing low-confidence or fully mitigated findings as tickets trains teams to ignore security tooling. Each false positive or irrelevant finding filed as a bug reduces engagement with the system’s output. A pipeline that produces ten confirmed findings gets more engineering attention than one that produces two hundred maybes. Validation results We tested the steering file against a purpose-built vulnerable application containing ten known vulnerabilities: eight exploitable and two mitigated by infrastructure controls. The application includes an AWS WAF with SQL injection rules in blocking mode, Amazon Virtual Private Cloud (Amazon VPC) -isolated AWS Lambda functions, and IAM authentication on each endpoint. Without the steering file , the model found all ten vulnerabilities and correctly identified both mitigated findings as lower priority. However, it assigned severity based on intuition ( this is a command injection, so it’s CRITICAL ) rather than evidence, and it produced no structural verification of its claims. With the steering file , the model found nine of ten vulnerabilities (not flagging a hardcoded credential that had been intentionally embedded in unit-testing code and was defined but never called), correctly downgraded the two mitigated findings to P3 with documented rationale, showed its confidence calculation for each finding, and verified each claimed dataflow against the actual code. The scoring calibration required one iteration. Our initial version applied authentication as a blanket multiplier that suppressed all findings behind IAM to P2 regardless of impact. We corrected this by separating access-limiting controls (which reduce the reachability score component) from attack-blocking controls (which reduce the full confidence score). The current version correctly classifies a command injection behind IAM authentication as P0: the auth limits who can reach it, but the impact when exploited is remote code execution regardless. How to use the steering file The three options that follow cover an always-on Kiro steering file, the same content as an on-demand Kiro skill, and how to carry the same content to Claude Code or another assistant. Option 1: As a Kiro steering file Drop the steering file into your repository at .kiro/steering/vuln-triage.md . Any session using Kiro’s built-in default agent loads the instructions automatically. When you or your engineers ask the model to analyze code for security issues, it applies the methodology without additional prompting. If your team uses a custom agent rather than the default, steering files aren’t loaded automatically; you have to add the file to the agent’s resources explicitly: { "resources": ["file://.kiro/steering/**/*.md"] } your-repo/ ├── .kiro/ │ └── steering/ │ └── vuln-triage.md ← steering file ├── src/ ├── cdk/ └── ... You can also place it in ~/.kiro/steering/ to apply the methodology across every workspace on your machine, rather than scoping it to a single repository. Option 2: As a Kiro skill If you want the methodology available on demand rather than consuming context window space in every turn, place it as a skill. Kiro loads only the skill’s name and description at startup and pulls in the full instructions when the skill activates. This keeps the instructions out of unrelated conversations. A skill is a folder containing a SKILL.md file. The folder name must match the name in the YAML front matter: name: vuln-triage description: Structured vulnerability triage methodology with evidence-based scoring and infrastructure-aware prioritization. Use when analyzing code for security vulnerabilities. your-repo/ ├── .kiro/ │ └── skills/ │ └── vuln-triage/ │ └── SKILL.md ← skill file ├── src/ └── ... Kiro’s default agent discovers skills in .kiro/skills/ automatically; no configuration required. The skill then activates either automatically, when Kiro matches a request against the description, or explicitly as a slash command. A skill named vuln-triage becomes /vuln-triage , so an engineer can run an assessment on demand: > /vuln-triage focus on the authentication changes Place skills in ~/.kiro/skills/ to make them available across every project on your machine. If your team uses a custom agent rather than the default, skills aren’t loaded automatically, you must add them to the agent’s resources: { "resources": ["skill://.kiro/skills/*/SKILL.md"] } Option 3: Adapted for other tools The methodology isn’t specific to Kiro. The repository also ships the same content as a CLAUDE.md file for Claude Code, and the principles apply to any assistant that loads persistent instructions from your repository—consult your tool’s documentation for the filename and location it expects. What this doesn’t replace A steering file is methodology, not machinery. It tells the model how to think about findings but doesn’t provide: Programmatic taint tracking: The model approximates dataflow by reading code. A purpose-built taint tracker confirms dataflow against the abstract syntax tree (AST) deterministically. For Python codebases, static analysis tools built on parsers like Tree-Sitter provide this. For other languages, the model’s approximation is reasonable but not authoritative. Live infrastructure verification: The steering file instructs the model to parse IaC files. It can’t make API calls to verify that an AWS WAF rule is attached to the Amazon API Gateway in your deployed environment, or that a security group hasn’t been modified since deployment. Threat intelligence feeds: The file instructs the model to consider CISA Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS) data. The model’s training data includes historical KEV entries, but it can’t query live feeds. For current exploitation status, you need an API integration. Execution-based verification: The steering file produces assessed findings. Confirming exploitability by executing a proof of concept against a live environment requires additional tooling: a sandbox, request signing, and differential testing infrastructure. Each of these capabilities adds confidence to the pipeline. The steering file without them still produces measurably better results than an unsteered model: structured findings, cited evidence, and infrastructure-aware prioritization. But it represents the first layer of a mature harness, not the complete system. What comes next The steering file gives your team a structured methodology for AI-powered vulnerability triage today. It works with the tools you already have. It works without infrastructure changes, new services, or a procurement process. The steering file is available in our GitHub repository . We encourage you to use it, adapt it to your environment, and let us know what you find. The authors work on security automation at AWS. The patterns described here emerged from building and validating AI-powered vulnerability detection systems across multiple teams and deployment environments. If you have feedback about this post, leave a comment in the Comments section below. Justin Kontny Justin is a Senior Software Engineer, Security, at AWS who blends a passion for software development with deep expertise in cloud security. He focuses on building agentic security solutions using AI-Driven Development Lifecycle (AIDLC) practices, transforming security from a barrier into a business enabler. Outside of work, Justin enjoys spending time with his children and staying active outdoors. Ievgeniia Ieromenko Ievgeniia is a Software Development Engineer at AWS, where she builds tooling and agentic AI systems designed to strengthen security posture without slowing delivery. Outside of work, she enjoys traveling, volunteering, and outdoor adventures with her very good dog, Pickle. Nidhi Ramakant Nidhi is a Software Development Manager at AWS with two decades of experience in security and enterprise architecture. She’s obsessed with helping customers secure their environments and building creative solutions that make security decisions easier. She’s equally invested in developing the talent around her. Outside work, she’s either binging shows or vibe coding apps for secure local LLMs so her kids can explore and learn safely.

The FBI is warning that FortiBleed attacks are still ongoing, targeting exposed Fortinet FortiGate firewalls and SSL VPN gateways and locking out legitimate administrators. [...]

Hackers obtained unauthorized HTTPS certificates for several Google domains and hijacked domains in the country-code top-level domains (ccTLDs) for Ghana, American Samoa, and Sierra Leone after compromising third-party operators and modifying authoritative DNS records. [...]

Imagine going to a Google website at its correct URL, only to be redirected to a crim's illegitimate copy. Attackers hijacked top-level domains, allowing them to alter DNS records and mint fraudulent HTTPS certificates for several Google domains, and those belonging to other organizations. Google said it became aware of the series of attacks last week in the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) country-code top-level namespaces (ccTLDs). “During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations,” Google security warned on Tuesday. Google did not say which specific domains or organizations were affected. The attacks did not compromise Google’s systems, and Chrome quickly blocked suspected counterfeit certificates across the affected ccTLDs - meaning Chrome browser users are already protected - according to the Chocolate Factory. “Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong,” the alert said. These types of attacks allow criminals to impersonate legitimate organizations and websites without triggering any browser security alerts. The attacker controls the traffic routing (via DNS) and the private key associated with the unauthorized certificate, which means they can potentially intercept or modify data sent by users to the impersonated site - and abuse the trusted organization's brand to distribute malware or conduct phishing attacks. “While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users,” Google warned domain owners. “Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.” To ensure that their domains and users are protected, Google recommends ongoing monitoring of Certificate Transparency (CT) logs across all of an organization’s domains, including parked or regional ccTLD properties. This provides near real-time alerts whenever someone obtains a certificate for one of your domains. And if you operate a domain in .gh, .sl, or .as, definitely review recent CT log entries for unexpected certificates. Organizations can also publish restrictive Certification Authority Authorization (CAA) DNS records, which allow domain owners to specify which CAs are permitted to issue certificates for their domains. While this won’t stop certificates from being issued during a DNS hijacking attack, it helps safeguard domains after DNS control is restored. Google recommends CAA policies that restrict issuance to specific authorized accounts and validation methods and prevent attackers from using cached validation state to mint new certificates after a hijacking ends.®

We recently published a post on “tokenomics” and “denial of wallet” attacks — a new type of DDoS attack aimed at overspending AI tokens. But before security specialists begin protecting their colleagues’ AI processes from this new threat, they should remember that the work of the information security department itself can become a target for such an attack. Since security teams are now actively testing and implementing various types of AI-based automation, the threat of external interference aimed at paralyzing the defense system directly affects their own processes and technologies. Elastic has estimated that, depending on the “agent-based SOC” architecture, triaging a single alert from a host can cost $0.69 for an ensemble of highly specialized agents or $3.42 for a general-purpose agent with 14 different skills. However, these averages mask a huge range of variation. At any given moment, the basic processing of a simple alert (say, a thousand tokens) can turn into a cascading investigation involving processing millions of log entries, API calls, and other related data — which amounts to millions of tokens in a matter of minutes . Elastic itself acknowledges that it uses the Claude Sonnet 4.6 model in its SOC. This immediately raises the question: what happens when the budget is exhausted or the model’s security filters are triggered? In the worst-case scenario, the following occurs: the AI SOC launches an “orchestra of agents” to investigate suspicious events that resembles lateral movement in the infrastructure. The agent calls the Anthropic API, but the department’s monthly budget has been exhausted, and the API returns errors. The investigation grinds to a halt, and people find out about it half a day later. Moreover, if the constantly changing “security filters” of a major AI provider flag the SOC’s requests as malicious, the same effect is possible even without the budget being exhausted — as demonstrated by Hugging Face’s experience investigating the breach of their infrastructure by OpenAI. Of course, an attacker has a vested interest in such an outcome. They can directly influence the defenders’ costs by injecting malicious prompts into the data available to them (DNS TXT records, HTTP headers, code comments, filenames, and so on), counting on the fact that these prompts will be processed by information security systems. For example, in the GhostJacking attack case, WAF logs serve as the vector for prompt injection, and in academic study, another method was proposed: researchers managed to attack the LLM security guardrails themselves , causing their requests to increase latency by 148 and the number of tokens consumed by 63. In other words, the system theoretically continues to function correctly, but the latency in processing alerts and the associated costs increase significantly. Dangerous silent failure In agent-based scenarios, budget exhaustion doesn’t always manifest as an explicit error with a “request limit exceeded” message and an immediate alert to the responsible parties. Under certain configurations, “guerrilla” scenarios can arise: a request to the model times out, the system automatically switches to a cheaper model, and as a result the quality of its outputs drops, and subagents and periodic tasks stop running. Meanwhile, the security team may continue to believe for hours on end that everything is working as before. How to control AI costs in cybersecurity The task of managing expenses, of course, isn’t simply a matter of “preventing overspending”. The industry has already fallen into this trap when implementing SIEM: when companies had to pay based on the volume of telemetry collected, they began to selectively — and not always effectively — limit log collection. As a result, they ended up with detection blind spots. The same situation could arise with tokens — but faster and on a larger scale. A poorly designed cost-cutting policy could compromise the depth of investigations and the quality of responses. And in the absence of such a policy, the decision to cut something will be made not by the architect or the CISO during the system design phase, but by the analyst on duty at 3am. Or it may be an automatic limiter set by the system vendor. A few simple principles can help avoid predictable cost overruns, and better manage situations that are truly unpredictable. Don’t feed the AI model anything that can be verified with a standard query. Everything that’s repetitive and known in advance should be handled the old-fashioned way — with rules and data queries. These can be developed using AI, but they must operate deterministically. The model should only be used where an assessment of an ambiguous situation is truly needed. Use strict limits and aggressively alert users when they are exceeded. Limits should be combined: a limit per task, a daily limit, and so on. Alerts about limit exceedances must immediately reach both on-duty analysts and those responsible for the system as a whole. Decide in advance what happens when a limit is reached. Whether to stop and save money — while losing some control — or to continue and pay, is a decision that must be made before an incident occurs. Limit agents’ permissions and the set of tools available to them. The fewer actions the system has access to, the more effectively it works on a narrow task, the fewer opportunities it has to inflate costs, and the less likely it is to be “exploited” by an outsider. Strictly scan external, untrusted data. Incoming requests, inquiries, messages, and comments, as well as various technical fields capable of containing arbitrary text (DNS records, HTTP headers, file names) can not only lead to prompt injection, but also deliberately inflate the workload. Limit their size, and monitor the load they generate. To avoid service outages from external providers and maintain full control over your organization’s data, evaluate the possibility of using local models deployed on-premises at least for information security needs. While these models may not be state-of-the-art, their narrow specialization and fine-tuning with company data will deliver decent performance without unexpected failures. In a more complex architecture, the use of LLMs can be divided into several levels . The first line of defense (routing, noise filtering, data enrichment) is handled by compact on-premise models. This significantly reduces budget volatility. The second level consists of a large local model that handles the substantive work: linking events, testing hypotheses, and piecing together the picture of an incident. It’s also not billed per request, but its throughput is limited; therefore, instead of budget overruns, overloads and event queues may occur. Only isolated, truly difficult cases are forwarded to advanced cloud-based models — preferably with the explicit approval of a human analyst. In this scheme, variable costs remain, but they’re limited to a small number of cases, and each one represents a conscious choice rather than a side effect of a script running overnight. Essentially, all of this replicates the classic multi-tiered SOC model — where the first line filters, and the third line investigates — only the roles are played by models rather than people.

It was discovered that Go Networking did not properly handle server errors after sending a GOAWAY frame during HTTP/2 connection shutdown, which could cause the connection to hang. A remote attacker could possibly use this issue to cause a denial of service. (CVE-2022-27664) It was discovered that Go Networking had quadratic complexity when decoding HPACK headers in HTTP/2 streams. A remote attacker could possibly use this issue to cause Go Networking to use excessive resources, leading to a denial of service. (CVE-2022-41723) It was discovered that Go Networking incorrectly rendered text nodes outside of the HTML namespace literally, causing text that should be escaped to not be escaped. A remote attacker could possibly use this issue to perform cross-site scripting attacks. (CVE-2023-3978) Guido Vranken discovered that Go Networking processed certain inputs to the HTML parsing functions non-linearly with respect to their length. A remote attacker could possibly use this issue to cause Go Networking to use excessive resources, leading to a denial of service. (CVE-2024-45338) Sean Ng discovered that Go Networking incorrectly interpreted tags in foreign content with unquoted attribute values ending with a solidus character as self-closing, which could result in content being placed in the wrong scope during DOM construction. A remote attacker could possibly use this issue to perform cross-site scripting attacks. (CVE-2025-22872) It was discovered that Go Networking had quadratic parsing complexity when processing certain HTML inputs. A remote attacker could possibly use this issue to cause Go Networking to use excessive resources, leading to a denial of service. (CVE-2025-47911) It was discovered that Go Networking could enter an infinite loop when parsing certain HTML inputs. A remote attacker could possibly use this issue to cause Go Networking to use excessive resources, leading to a denial of service. (CVE-2025-58190) It was discovered that Go Networking incorrectly accepted Punycode-encoded labels that decoded to ASCII-only labels when processing internationalized domain names. A remote attacker could possibly use this issue to bypass access control restrictions and escalate privileges. (CVE-2026-39821)

Attackers compromised three country-code top-level domains (ccTLDs) and obtained unauthorized HTTPS certificates for several Google domains, Google said on October 6. Google's own systems were not breached, but any domain ending in .gh (Ghana), .sl (Sierra Leone) or .as (American Samoa) was put at risk. With such a certificate, an attacker could pose as the real site over an encrypted

Cybersecurity researchers have disclosed details of a long-running npm supply chain malware campaign that pushes information stealers and remote access trojans (RAT) to compromised hosts. The campaign has been codenamed MALFEX by CloudSEK and Checkmarx. The activity is assessed to be the work of a lone threat actor who appears to have published 12 packages since August 2023, eight of which have

AWS has offered multiple open-source strategies for holding AI agents accountable, and now it’s adding a full-on sandbox to this stack. Dubbed Strands Box, the new solution uses OS-level isolation and some of AWS’ other recent open-source AI control tools to, ostensibly, retain greater control over autonomous AI agents’ behavior. “Agents increasingly run in ‘YOLO mode,’ approving every action without human review,” the AWS team explained in its announcement. “The usual solution to this problem is a sandbox … but access is only part of what we want to control.” The problem with containers and microVMs typically used to isolate AI agents, as AWS explains it, is that their strong isolation doesn’t come with contextual rule enforcement. In other words, when a containerized or virtualized agent gets hold of a tool, there may be no stopping it from doing whatever it wants - like deleting a production database, or gaining access to the internet and doing dog knows what. That’s where the other open-source tools inside Strands Box come in: It uses the Dogwood Local Engine to give the policy engine in Box temporal awareness, so tool calls can be checked against not only what the agent wants to do, but what it’s already done. As one example, AWS noted that an agent could be allowed to post status updates to Slack, but no more than three times every ten minutes to prevent it from spamming its human operators. An AWS spokesperson further explained that Box could be used to control when an agent can perform a Git push, or it could be used to put a cap on API calls that could end up costing a small fortune. Additionally, Strands Box includes Strands Shell and Monty for Python, which expose shell and Python operations to the same Dogwood policy engine and event history, making agentic actions clearer to developers and allowing policies to account for what an agent is trying to do. AWS VP and distinguished engineer Marc Brooker, one of the folks behind Dogwood and Strands Box, explained to The Register that the interpreters are a key part of making agentic behavior more intelligible, which allows for devs to write more precise policies to prevent agents from taking bad actions. “Box’s Shell and Python interpreters expose operations such as file deletions, while its gateways expose API requests and tool calls,” Brooker told us in an email. “Policies can then account for the action being attempted and earlier activity.” Box, Brooker added, enforces those rules without trusting or relying on agents to actually follow instructions, which should ideally prevent them from running roughshod over their operators’ wishes. As for the reason behind AWS’ push to develop open-source tools like Dogwood, the Dogwood Local Engine, and Strands Box, Brooker said that AWS wants to find the right balance between boundaries and policies that prevent agentic AI disasters of the kind we regularly report. “Box enforces the policies developers configure, deterministically, and the agent can't talk its way around these rules,” Brooker explained, though he added that, even with properly configured permissions, an agentic action can still produce an unwanted result. “Developers remain responsible for deciding what access to grant and where human review is needed,” Brooker added - in other words, don’t let your YOLO mode go too YOLO. A bit of human oversight is still necessary. “Agent safety is an area where the industry still has significant work to do, and we're committed to continuing to invest in it, both inside the AWS cloud and in open source,” Brooker said. Strands Box supports any agent or harness one wants to confine within its walls and is available on GitHub now, though only for macOS for the time being. Linux support is in development, and AWS told us a Windows client is “on our radar,” but neither has a planned release date. Deployment to platforms like AgentCore, ECS, and Kubernetes is also planned. ®