❌

Normal view

There are new articles available, click to refresh the page.
Today β€” 11 August 2026Main stream

NATO and an AI startup can now name and track software vulnerabilities

By: Greg Otto
10 August 2026 at 15:50

NATO’s cyber defense arm and a startup that uses artificial intelligence to find software flaws can now issue the ID numbers the industry uses to track those flaws, the European Union Agency for Cybersecurity announced last week.Β 

The NATO Cyber Security Centre, part of the NATO Communications and Information Agency, and AISLE, a cybersecurity company with offices in San Francisco and Prague, joined as CVE numbering authorities under the ENISA Root. The CVE program assigns a unique record to each publicly disclosed security flaw so that governments, vendors and researchers have a common marker when referring to particular vulnerabilities.Β 

Twenty numbering authorities now sit under the ENISA Root, with 12 brought in by ENISA itself and eight moving over from the MITRE Root, run by the U.S. nonprofit that has handled the program’s daily work for more than 20 years.

Hans de Vries, ENISA’s chief cybersecurity and operations officer, linked the growth to changes in how people find flaws.Β 

β€œRecent developments in the global cybersecurity landscape, coupled with the emergence of Frontier AI models and their impact on vulnerability discovery and exploitation, have underscored the need to build strong vulnerability management infrastructure and capabilities,” he said in a statement. He said ENISA’s role helps build a β€œmore globally representative, resilient, and scalable vulnerability identification ecosystem.”

The two new members show how bespoke each member is within its authority. The NATO Cyber Security Centre can now assign CVE IDs to eligible flaws across the NATO enterprise. The agency said that will make tracking more consistent and let the alliance share information with trusted partners sooner. The center guards NATO’s networks, watches for threats and coordinates the response when incidents hit.

Meanwhile, AISLE’s authorization is narrower. The company said in a July press release that the designation covers vulnerabilities discovered in its own products, allowing it to publish identifiers without waiting for a third-party authority to process a request.Β 

Jaya Baloo, the company’s co-founder, described the step as β€œfoundational” and said coordinated disclosure β€œstarts with holding your own products to the same standard you expect of everyone else.” Separately from the designation, the company said its researchers have disclosed hundreds of vulnerabilities in widely used open-source software, including OpenSSL, Linux, Apache and OpenEMR, each coordinated through the relevant authority for that project.

The changes come as the CVE process continues to involve amid program upheaval and the torrent of vulnerabilities discovered by AI systems.Β 

The CVE program, run by CISA, narrowly escaped a sudden demise when a last-minute, 11-month contract extension averted a shutdown in April 2025. Since then, several competing databases from European nonprofits and other private entities have been stood up in order to better coordinate how vulnerabilities are tracked, disclosed, and ultimately patched.

Earlier this year, The Computer Incident Response Center Luxembourg (CIRCL) launched the Global CVE Allocation System, or GCVE, as an alternative to the CVE program.

The post NATO and an AI startup can now name and track software vulnerabilities appeared first on CyberScoop.

Yesterday β€” 10 August 2026Main stream
Before yesterdayMain stream

Open-source software’s archenemy TeamPCP goes back further than anyone thought

5 August 2026 at 09:00

TeamPCP, the threat actor behind an unrelenting flurry of attacks on open-source software this year, has been active much longer than previously thought, according to research Oligo Security shared exclusively with CyberScoop.Β 

The threat actor, which gained notoriety and has captivated threat hunters as it compromised and injected malicious code into more than 1,000 software packages in less than four months earlier this year, was also responsible for attacks dating back to 2020, Oligo Security found.Β 

The security vendor’s research team found multiple attacks that bear the markings of TeamPCP, including a late 2025 campaign involving the exploitation of a ShadowRay vulnerability that resulted in the first self-propogating botnet running on hijacked AI infrastructure.

Evidence uncovered during that investigation into the ShadowRay 2.0 campaign was linked to more historical attacks originating from the same IPs, domains and other infrastructure TeamPCP used in attacks that captured widespread attention earlier this year.Β 

β€œThe scariest thing in this campaign is the speed at which the payloads evolved and changed and adapted to the environment they run in. We saw changes in the speed that we’re not used to seeing in these kinds of attacks. They’re usually slow, careful,” said Uri Katz, director of research at Oligo Security. β€œThis was clearly with the help of AI β€” the payloads changed rapidly to adjust and change to the environment that they were trying to attack.”

One of the domains that Oligo Security identified in July 2025 was in the profile of TeamPCP’s official GitHub account, said Avi Lumelsky, AI security researcher at Oligo Security. β€œIt’s public, they’re not even trying to hide their identity,” he said.Β 

From there, Oligo linked TeamPCP to activity tracked under multiple names, including TA-NATALSTATUS and IronErn, spanning from 2020 to late 2025. Much of that activity was traced to the same IPs, domain names, a file server and command-and-control server, researchers said.Β 

TeamPCP emerged publicly as a brand in late 2025. Soon after, β€œTeamPCP started to go really broad and do campaigns, which are much more noisy,” said Gal Elbaz, co-founder and CTO at Oligo Security.Β 

Widespread adoption of AI and TeamPCP’s use of the technology supported this growth as the threat actor built a brand, got more active on social media and boasted publicly about its activities and claimed victims.

β€œThe ability to control the infrastructure and orchestrate the attack with AI was also super new, and I’m sure it helps them,” Elbaz said.Β 

β€œAll of the companies in the world are in this race to adopt AI because they are afraid their business will die, and they understand, of course, the opportunity. But it’s also what gives the attacker this power to go into it,” he added. β€œIf you don’t really have visibility in what’s going on there or how it behaves, that’s exactly what attackers are after.”

TeamPCP’s more recent attacks have capitalized on new security gaps created by developers’ increasing reliance on AI and the automated systems companies use to deploy code. The threat actor is also consistently wrecking the open-source frameworks and software packages these systems rely on.Β 

β€œMost AI infrastructure is open source by design because nobody has the manpower and money to develop everything from scratch,” Lumelsky said.Β 

β€œWe love open source. We use many of these products ourselves, but it’s all about reading the documentation, and I think many of these tools place the responsibility of using it right and security on the user, and developers are not used to these new kinds of animals,” he added. β€œThat’s why the trust can be exploited at scale.”

As it uncovered a long operational history spanning multiple campaigns, Oligo Security has gained more confidence in understanding how TeamPCP operates. It also means TeamPCP was likely involved in other attacks that haven’t been attributed to it yet or attacks that haven’t been detected.Β 

β€œThere’s a lot more out there that we haven’t caught or been able to prove up until now,” Elbaz said.

The post Open-source software’s archenemy TeamPCP goes back further than anyone thought appeared first on CyberScoop.

Prolific ransomware group behind SonicWall zero-day attacks

4 August 2026 at 11:20

Researchers said INC ransomware, one of the most active ransomware groups globally, has been the main attacker exploiting a pair of SonicWall zero-days soon after they were disclosed last month.

The prolific ransomware-as-a-service operation wasn’t the first group to exploit the flaws, which were actively exploited for three weeks before the vendor disclosed and patched the defects July 14, but it has been the most assertive and concerning group to target and chain both vulnerabilities together for full access.

β€œSince public disclosure, INC ransomware has emerged as the most commonly named threat actor actively weaponizing this vulnerability chain,” Brett Deroche, director of incident response at Rapid7, told CyberScoop. β€œWhile Inc is the name driving the post-disclosure wave, we can’t attribute the full body of exploitation to INC specifically.”

SonicWall did not respond to a request for comment.

The SonicWall vulnerabilities β€” CVE-2026-15409 and CVE-2026-15410 β€” are the latest in a series of security issues confronting the vendor’s customers, including actively exploited zero-days, previously disclosed defects, and an attack last year that allowed a state-sponsored threat group to steal the firewall configurations of every SonicWall customer.Β 

Just last week, Huntress researchers spotted an attack spree that compromised 30 SonicWall customers in less than two days.Β 

Ransomware groups have taken a special interest in SonicWall. Ten of the 17 SonicWall defects added to the Cybersecurity and Infrastructure Security Agency’s known exploited vulnerabilities (KEV) catalog since late 2021 are known to be used in ransomware campaigns.

INC ransomware, which has claimed nearly 900 victims across 71 countries since it was first discovered three years ago, is just the latest financially-motivated group to target SonicWall customers.Β 

Researchers haven’t determined how many organizations have been impacted by the latest SonicWall zero-days, including attacks linked to INC ransomware.Β 

β€œAttribution here isn’t a single clean answer. The earliest exploitation we observed, beginning June 22, traced back to common hosted infrastructure, though those attacks were largely unsuccessful,” Deroche said.Β 

β€œINC’s confirmed activity that we’ve observed came after public disclosure, using different infrastructure and moving from initial access to ransomware deployment in short order. That’s a meaningfully different operational tempo and skill level than what we saw pre-disclosure,” he added.Β 

Deroche said Rapid7 has successfully prevented data theft and encryption in the majority of recent cases, yet noted ransomware was deployed in at least one case the security vendor observed.

Yet, there could be other attacks outside the purview of Rapid7’s telemetry. INC ransomware has listed multiple new alleged victims on its data leak site, including organizations and government agencies in Australia, the United States, the United Arab Emirates, Colombia and Switzerland, Resecurity said in a blog post Saturday.

The company said it has aided several victims with incident response, and learned multiple victims received emails and phone calls from alleged hackers who pressured them to engage in negotiations.

The post Prolific ransomware group behind SonicWall zero-day attacks appeared first on CyberScoop.

How companies could share cyber risks without exposing their secrets

By: Greg Otto
4 August 2026 at 06:00

Zero-knowledge proofs could let infrastructure operators answer key security questions without handing over the sensitive data behind their answers.

Imagine a major software flaw is discovered in equipment used across pipelines, power plants and telecom networks. The government needs to know as fast as possible which companies are exposed. But answering that question may require firms to share software inventories, network diagrams and vulnerability scans, which could become attack roadmaps for attackers if compromised. A lesser-known cryptographic concept could help solve this problem. The method, known as zero-knowledge proofs, allows companies prove a vulnerability exists without disclosing how their systems work or other proprietary information.

For more than a decade, Washington has tried to address companies’ concerns about sharing cybersecurity data. Congress has provided legal protections, and agencies have created information-sharing programs. Those efforts have helped companies exchange signs of an attack, incident reports, and defensive advice. But they’ve done much less to get companies to share data on vulnerabilities and security controls before an incident occurs.

The data that would help the most is what companies are least willing to share. A vulnerability scan can show which devices are connected, which software is running, how systems are configured and where defenses are weak. If unintentionally exposed, it would be a terrific guide for adversaries.

Another problem: Once sensitive data leaves a company, it can be stolen, subpoenaed, passed to another agency or used in a regulatory proceeding the company never expected. Industry is constantly asked to reduce security risk by creating more elsewhere.

Zero-knowledge proofs could reduce the need to disclose the underlying sensitive data. The idea is simple, even if the math is not: a company can prove that an agreed evaluation of its authorized scan data indicates that a specific software flaw is present, without disclosing its full asset inventory, network architecture or configuration data.

A computer does not read a vulnerability scan the way a person does. A security analyst might open a report, look through the devices and software versions, and decide whether a vulnerable product is present. A zero-knowledge proof turns that same evaluation into a local mathematical calculation.

For example, the government and a company could agree on a precise question: Does a specific vulnerability exist anywhere inside a defined group of systems? The company keeps its scan data inside its own network. A cryptographic tool checks that data against the agreed question, compares the software and version information against the vulnerability, and produces a proof tied to the final answer. If the scan data satisfies the agreed conditions for a β€œyes” result, the company cannot generate a valid proof supporting a false β€œno” answer under those same rules.

The government never sees the raw scan report, the device list, the software inventory, or the network map. It only receives and verifies the mathematical proof, confirming that the answer follows from the agreed rules and underlying data without exposing that data.

This isn’t theoretical. FDD’s Center on Cyber and Technology Innovation recently tested the approach with anonymized vulnerability data from three operational environments. The test asked yes-or-no questions about 38 known vulnerabilities while keeping the raw scans inside the participating environments. Results were promising: only the proofs and answers were shared, yet they revealed how widespread each vulnerability was across the environments.

The test proved the approach works, but that does not mean the government should rush to build a national system around it. A lot of work still needs to be done before agencies can rely on these for compliance, vulnerability reporting, or procurement decisions.

The next step should be structured pilot programs, not mandates. Federal cyber officials and standards bodies should test this with narrow, practical questions: whether a known vulnerability is present or whether a specific security control is in place.

Only after those pilots should agencies decide what underlying data can be trusted and what counts as sufficient proof in a regulatory setting. The Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology (NIST), and regulatory agencies are natural candidates to run these pilots. CISA already works with critical infrastructure operators on cyber risk, while NIST can help define what a trustworthy proof should look like before agencies try to rely on one. Regulatory agencies, meanwhile, could reduce private sector headaches by developing more secure mechanisms for companies to share compliance information.

Zero-knowledge proofs won’t solve every problem when it comes to cyber information-sharing. But they could solve one of the hardest: how to give the government a trustworthy answer without forcing companies to expose the very systems everyone is trying to protect. The government should test this concept now, while there is still time to learn, and avoid blindly entering the next cyber crisis.

The post How companies could share cyber risks without exposing their secrets appeared first on CyberScoop.

❌
❌