TeamPCP is on a rampage through open-source software.

In less than four months, the threat actor has compromised and injected malicious code into more than 1,000 software packages. The extraordinary spree has transformed how software developers and maintainers distribute and manage their code, as their dependencies and repositories have become one of the most effective and prevalent attack vectors this year.

While there has been a host of technical exploits, TeamPCP’s greatest attack has been the uprooting of trust — repeatedly proving that most organizations fail to verify the code they ingest into their systems is legitimate, abusing a nearly blind faith that much of the software development industry relies on to power today’s modern economy.

Starting with Trivy in February, TeamPCP’s attacks have shaken that trust many times over.

The scale of TeamPCP’s attacks lies partly in the automated systems companies use to deploy code, like CI/CD pipelines. It is also capitalizing on new security gaps created by developers’ increasing reliance on AI. Yet, with relatively low effort and unoriginal tactics, TeamPCP is wrecking open-source frameworks and underlying systems at levels the technology community has rarely reckoned with.

“Developers didn’t do a great job of analyzing the security of their open-source dependencies before but, now with AI, there’s in some cases virtually no human in the loop or any kind of sanity check on what these tools are doing,” Feross Aboukhadijeh, founder and CEO at Socket, told CyberScoop.

“You have agents installing packages that haven’t been vetted,” he said. “When an attacker gets in, the impact is even broader because there’s less checks and balances to stop it from affecting everybody.”

TeamPCP hasn’t identified a new problem or proved anything novel. The crux of these attacks hinge on a central theme — defensive vulnerabilities the entire software industry has known about for years. Researchers and developers know the open source trust model is broken and susceptible to sabotage. Yet, the software industry has not fixed this problem. 

“The speed and scale of these attacks is what makes it most notable, not necessarily the methodology behind it, because at the core it is really about exploiting third-party trusts that we have,” said Kimberly Goody, senior manager at Google Threat Intelligence Group.

Software packages are typically subjected to intensive security monitoring to test for vulnerabilities and poisoned updates before they are released to live environments. 

Yet, the real vulnerability highlighted by TeamPCP lies further up the chain of command with the organizations or individuals that publish these packages to the wider market, according to Nathaniel Quist, manager of cloud threat intelligence at Palo Alto Networks.

“It is their responsibility to secure their credentials and not provide a jump off point to trigger a supply-chain event,” he said. “Everything that interacts with or crosses through that zone must be highly monitored and controlled to ensure a compromise can be contained quickly and easily.”

TeamPCP’s motivation

TeamPCP, like any prolific cybercriminal, has captured significant attention from threat hunters since it emerged in late 2025. Google attributes the activity to one core operator.

The company said it traced TeamPCP’s residential and mobile IP address connections to South Africa, indicating the primary operator was located there during at least some of its attacks.

“We don’t believe that there’s an established core group, at least not yet, and that a lot of this has been conducted by an individual,” Goody said. Google declined to name the core operator or confirm it knows the person’s true identity. 

Palo Alto Networks said the core manager of TeamPCP uses the “ResoluteXBF” handle on multiple platforms. The cybersecurity firm is also tracking two additional core members: “diencracked” and “Shinigami.”

If TeamPCP is primarily run by one person, law enforcement has a rare opportunity to make a lasting impact with a single arrest.

TeamPCP has collaborated with other cybercriminals, but most of those partnerships were short-lived and ended in a public feud or otherwise failed to get off the ground in any meaningful way, Goody said.

Researchers have linked TeamPCP to extortion crews, dark web forums and affiliates including Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums and “HasanBroker.” TeamPCP listed about 4,000 private code repositories on a dark web forum with an asking price of $95,000.

The actions to date, including unpredictable behavior, indicate motivations beyond financial gain and a “clear desire for notoriety,” Goody said. “They seem to like to make chaos.”

Quist draws the same conclusion from his months-long investigation, noting that it encourages other cybercriminals to get in on the action, at one point offering financial rewards for the largest software supply-chain attack. 

TeamPCP isn’t in the game for extortion payments, he said. “These actors are more interested in the underground street cred they are gaining” and “causing as much damage and mayhem as possible.”

Victims abound, but exposure limited

TeamPCP has been remarkably noisy, opportunistically injecting malware into open-source software for the purpose of stealing credentials for Kubernetes environments, Amazon Web Services, Microsoft Azure, Google Cloud and many other connected services.

The group’s claimed victim list is staggering: Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat and Nx Console.

The full collection of packages compromised or poisoned by TeamPCP to date accounts for roughly 500 million weekly downloads combined, according to Quist.

While the breadth of potential downstream compromise flowing from those downloads is substantial, many endpoints infected with those malware-riddled packages aren’t exposed to the internet and less susceptible to attack, he added.

“I don’t think there’s going to be a very extremely large number of victims,” Quist said. “There’s going to be a lot of people who potentially could be compromised and have potentially vulnerable packages in their environment, but that doesn’t necessarily mean they’re in an exploitable position.”

While these incidents have grabbed headlines, TeamPCP hasn’t accumulated payouts nearly as large as other cybercriminals. The broader reputational impact it has wrought, however, is massive.

TeamPCP has publicly claimed more than 10,000 victims and about $90,000 in extortions, according to Quist.

“They might not be making a lot of money, but they are causing a lot of impact,” Goody said. “Their campaigns have been very disruptive.”

How TeamPCP’s operating model targets development

TeamPCP’s victim list has grown as its hijacked open-source repositories on npm, PyPI, GitHub and other outsourced developer tools that are incorporated into upstream code running in production environments.

Developer laptops and other endpoints that are assigned to install, build and publish software widely contain keys and access to source code that create incredibly valuable supply-chain targets for attackers, Amitai Cohen, head of the attack vector intel team at Wiz, explained during a June presentation on TeamPCP at SleuthCon in Arlington, Va. 

The group targets CI runners, which are automated systems that build, test, and publish code. TeamPCP injects malware into the code repositories these runners maintain. When other developers pull that code into their own systems, they unknowingly download the malware alongside it. 

Some of these artifacts, including Python libraries, npm registries and GitHub Actions, are downloaded almost immediately by thousands or millions of developers who’ve set their runners up to consistently pull the latest version, according to Cohen. “We as a security industry have taught them that that is the right thing to do. You want to use the latest version because you want to be protected against vulnerabilities, and obviously you want to benefit from all the latest features.”

That instinct is exactly what TeamPCP exploits. By compromising one company’s CI/CD workflow, the group gains access to every downstream user who automatically pulls that infected code. “This is what allows [TeamPCP] to leverage initial access to some patient zero, some company that had a vulnerability in their CI/CD workflow, in order to gain access to their downstream users,” Cohen said. “That’s just how the software supply chain works. Everything has dependencies upon dependencies upon dependencies.”

Some of the packages compromised by TeamPCP were live for almost 13 hours, but security practitioners have responded by identifying code-injection attacks much quicker now, pulling some compromised repositories within 15 minutes, said Ben Read, director of strategic intelligence at Wiz.

The threat group’s operations remain high-tempo. TeamPCP infects new software packages almost daily, validates compromises and captures sensitive data within 24 hours, according to Wiz researchers.

The threat group has consistently evolved its tactics, developing payloads in JavaScript and Python while spreading from local files to Kubernetes application programming interfaces and bundled software development kits. Most recently, it’s been stealing credentials via custom protocols. 

The group’s ambitions have expanded beyond its own attacks. TeamPCP is also responsible for a self-replicating piece of malware known as Mini Shai-Hulud, which infected hundreds of software packages across open-source registries in back-to-back attack sprees last month. A TeamPCP affiliate published the full source code for the malware on GitHub last month and encouraged other cybercriminals to use it for their own campaigns.

“TeamPCP is going for volume. They are not being discriminating, they’re not necessarily trying to be stealthy or trying to maximize ROI. They’re going for an all-of-the-above strategy,” Read said during the Sleuthcon presentation.

Defensive gaps create openings for attack

TeamPCP’s attack spree has also underscored how difficult it is for organizations to revoke compromised secrets. Multiple victims have experienced recurring infections, sometimes falling prey to TeamPCP three times within a month, because they didn’t rotate secrets properly, Cohen said. 

At its core, these attacks highlight a direct trade-off organizations accept when they update software quickly to fix vulnerabilities, but learn that doing so too quickly could expose them to illegitimate registries containing malware.

TeamPCP has targeted what Aboukhadijeh describes as a “public good,” open-source registries that were never perfect but widely trusted and rarely turned into a point of entry for supply-chain attacks. 

Rapid open source software installation is one of the most dangerous things an organization can do right now, he said, adding that there’s a roughly 1 in 10 chance that any package installed by an organization could trigger an active attack. 

TeamPCP has compromised security scanners, password managers, automation tools, data visualization software, and CI/CD infrastructure across various environments.

And it’s lifted a trove of credentials and other sensitive data from victims.

Researchers like Cohen at Wiz, who have been tracking this attack spree since the beginning, are nearing a breaking point. 

“This is also too hard on us. We’re very tired. I’m sure a lot of people working on this problem space are very tired, and it’s just kind of become untenable,” Cohen said.

“You can’t keep existing in a world where you wake up every morning and some super prevalent package is compromised and everybody’s just going to be using it like nothing,” he added. “We need to start taking this a bit more seriously.”

The post How software development’s speed obsession enabled TeamPCP’s chaos crusade appeared first on CyberScoop.

GitHub said late Tuesday that internal repositories were exfiltrated after an employee device was compromised through a poisoned Visual Studio Code extension, an incident that underscores the growing risks facing software development platforms and the ecosystems built around third-party developer tools.

The Microsoft-owned company said in posts on X that it detected and contained the compromise, removed the malicious extension version, isolated the affected endpoint and began an incident response investigation. The company’s current assessment is that the activity involved GitHub-internal repositories only.

GitHub also said a claim from TeamPCP, a hacking group behind attacks targeting software development packages, that 3,800 repositories were impacted was “directionally consistent” with its investigation so far. It said critical secrets were rotated Tuesday, with the highest-impact credentials prioritized first. The company said it continued to analyze logs, validate secret rotation and monitor for follow-on activity.

The company has not publicly named the extension involved or attributed the activity to a particular group. TeamPCP reportedly advertised the material for sale on a cybercrime forum and threatened to release it if no buyer emerged. 

Information surfaced Wednesday that the incident may be related to a separate issue with Nx Console, a Visual Studio Code tool that helps engineering teams organize large codebases, coordinate build pipelines and run tests efficiently. According to a security advisory posted on GitHub, one of the Nx Console maintainers was compromised in a prior security incident that leaked their GitHub credentials. An attack then used those credentials to push a malicious version of the extension to the VS Code Marketplace. Those credentials have since been temporarily revoked.

With millions of installs, Nx Console is a fixture of professional JavaScript development. It is exactly the kind of tool that sits deep inside a developer’s working environment, which would have direct access to source code, credentials and build systems.

NX CEO Jeff Cross posted on X Wednesday that his company has been working with Microsoft to determine the full scope of the incident.

“Initially, Microsoft indicated to us that there were 28 installs of the malicious version 18.95.0. Based on our own analytics for the compromised version, we currently believe the number of users who received the malicious package may be significantly higher; potentially over 6k installs,” the post reads.

“This is my top priority right now,” Cross continued. “Our team has been, and continues to be focused on understanding exactly what happened, helping affected users, hardening our systems and release processes, and being as transparent as possible throughout the investigation.”

The episode also follows a series of supply chain attacks involving npm, PyPI, Docker and other developer ecosystems. In those incidents, attackers have often targeted maintainers, packages or credentials rather than attacking end users directly. The multiple attacks show how fragile development environments have become as threat actors increasingly target them. A single compromised developer account, package, extension or build process can create access to many downstream systems.

GitHub has said it has no evidence that customer data stored outside the affected repositories was affected.

Visual Studio Code extensions are widely used by developers to add functions to Microsoft’s code editor, including support for programming languages, testing tools, cloud services and artificial intelligence assistants. Because these extensions often operate inside development environments, a malicious or compromised extension can be positioned close to source code, credentials and build systems.

“The thing people underestimate about VS Code extensions is that they have full access to everything on the developer’s machine,” Charlie Eriksen, a security researcher at Aikido Security, told CyberScoop. “EDR doesn’t cover this layer at all. What’s missing for most organisations is any kind of visibility into what’s actually running on developer machines and the ability to control it.”

Trojanized extensions have appeared in the VS Code Marketplace before. Security researchers have identified malicious extensions posing as legitimate development tools, including packages used to steal credentials, mine cryptocurrency or exfiltrate data. Some have accumulated large installation counts before removal, reflecting the difficulty of policing open plugin ecosystems at scale.

For GitHub, the breach comes amid broader scrutiny of the security of developer infrastructure. The platform sits at the center of software production for companies, governments, open-source maintainers and independent developers. Its internal systems and code are of obvious interest to attackers because GitHub’s services support code hosting, package distribution, automation and identity workflows across much of the software industry.

GitHub said it would publish a fuller report when the investigation is complete.

Update: May 20, 12:55 p.m.: This story has been updated with information about a related security incident with Nx Console.

The post GitHub says internal repositories were impacted in poisoned VS Code extension attack appeared first on CyberScoop.

Congress wants answers from the Cybersecurity and Infrastructure Security Agency about the reported public exposure of sensitive agency credential data on GitHub in an incident that the security researcher who discovered it called one of the worst leaks he’s ever seen.

Other security professionals also voiced concern Tuesday about the leak and the potential for abuse by any malicious parties who got a hold of the information.

Security firm GitGuardian said it discovered a public GitHub repository last week that exposed credentials for privileged AWS GovCloud accounts and internal CISA systems dating back to November. The repository, apparently maintained by a contractor, was named “Private-CISA.” 

Krebs on Security first reported the incident.

“My main fear … is that a state actor will get the data and might be able to do bad stuff,” GitGuardian security researcher Guillaume Valadon told CyberScoop that he thought to himself upon discovering the leak, after concluding it was real; he initially thought it looked fake.

State-based attackers who obtained the credentials “might be able to gain persistence,” Valadon said, “so for me it’s even worse than an attacker destroying everything, having someone in a governmental system — it’s really, really bad.”

A House Homeland Security Committee aide said the panel is seeking a staff-level briefing from CISA on the matter.

Mississippi Rep. Bennie Thompson, the top Democrat on the Homeland Security Committee, and Delia Ramirez, the top Democrat on the panel’s cyber subcommittee, had separately demanded a briefing Tuesday in a letter to CISA’s acting director, Nick Andersen. 

They said they wanted to learn “how this serious security lapse occurred, any potential security consequences, remediation activities, corrective actions related to the contractor personnel involved, and efforts to monitor for and prevent similar activity from occurring in the future.”

Sen. Maggie Hassan, D-N.H., also sent a letter Tuesday to Andersen, seeking a classified briefing to answer questions about which systems were exposed, what forensic work CISA did to evaluate potential damage and what corrective action it has taken.

“This reported incident raises serious questions about how such a security lapse could occur at the very agency charged with helping to prevent cyber breaches,” Hassan wrote in the missive first reported by Axios, particularly “regarding CISA’s internal policies and procedures at a time of significant cybersecurity threats against U.S. critical infrastructure.”

Both letters pointed to personnel and budget cutbacks at the agency as a potential contributor to the incident.

CISA said it was looking into what happened.

“The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,” a spokesperson said. “Currently, there is no indication that any sensitive data was compromised as a result of this incident. While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.” 

The repository was reportedly maintained by a contractor at Nightwing. A Nightwing spokesperson referred questions to CISA.

The kind of exposure that happened for CISA “is an unfortunately painful, but common and repeated, if not relentless, way that we see organizations inadvertently leak very sensitive credentials to the wider web,” said Ben Harris, founder of WatchTowr, a company that helps organizations detect such exposures.

Harris told CyberScoop he didn’t want to speculate on what attackers who obtained the credentials might be able to do with it, but he said that it would be “terrifying” if the contractor was transferring information from work to home, as one researcher theorized.

Dave Mitchell, senior director of threat intelligence at Infoblox, told CyberScoop the incident showed the importance of teams having controls and audits in place across their repositories.

“Of all the things that keep me up at night, misconfigurations in GitHub are a recurring nightmare. It’s critical for so many organizations — all it takes is one accidental upload or misconfiguration and you’ve signed yourself up for a major incident,” he said in a written statement. “No need for a threat actor to use advanced techniques to compromise you if the keys are already sitting on the counter.”

Travis Rosiek, public sector chief technology officer at Rubrik, noted that the timing of the issue aligned with the government shutdown that only recently resolved for DHS. He said the incident showed the federal government needs to prioritize resilience.

“A persistent shortage of cybersecurity talent, combined with funding lapses, high workforce turnover, and an increasingly complex threat landscape, created the perfect storm for this scenario,” he said in a written statement to CyberScoop. “No organization is immune, and we must ensure that the federal government, which is responsible for helping protect the nation’s critical infrastructure and enhancing our cybersecurity posture, remains fully operational 24-7, 365 days a year.”

Without minimizing the severity of the incident, some researchers who have looked at the leak said there are mitigating circumstances that make elements of it defensible or, at least, understandable.

CISA acted very swiftly to remove the repository, Valadon said, once he alerted them to the leak.

And even if CISA has the right policies in place, human error still can make it difficult to entirely avoid incidents like this, Harris said.

“The reality is this happens every single day to different organizations, including cybersecurity companies,” he said, noting it would be different if it was a pattern. “This is not exclusive to CISA. I don’t really think it reflects well if we saw this every single day with CISA. … It’s not ideal that it’s even happened once, but the reality is that cybersecurity is people, process, technology.”

CISA has had other security incidents in the past, including recently. The former acting director of the agency endured criticism for uploading sensitive contract data to ChatGPT last year. In 2024 the agency notified Congress of a breach of a chemical plant security tool.

Updated 5/20/26: to include more information on a House Homeland Security Committee briefing request.

The post CISA credential leak raises alarms, and Capitol Hill demands answers appeared first on CyberScoop.

A self-replicating malware campaign known as Mini Shai-Hulud has resurfaced, this time embedding itself across hundreds of npm packages. The threat actor behind it, identified as TeamPCP, has been linked to earlier waves of the same campaign, with this latest variant more capable than previous waves.

Researchers analyzing the payload found a worm that spreads autonomously, installs persistent backdoors at the operating system level, and is specifically engineered to survive the most common first response: removing the package.

How the attack works

The malware executes the moment an affected software package is installed, whether in a developer’s local environment or inside a CI/CD pipeline. A hook fires before any other step, giving the payload immediate access to the machine.

It harvests GitHub tokens, npm tokens, SSH keys, cloud provider credentials, and database connection strings. In automated build environments, it uses the pipeline’s own trusted identity to obtain publishing credentials, allowing it to push poisoned package versions to the registry under a legitimate maintainer’s name. The stolen data is sent to attacker-controlled GitHub repositories.

After it steals a publishing token, the malware checks every package that token can access, adds its code to those packages, and publishes new poisoned versions using the maintainer’s account. One infected CI runner — the machine or virtual server that automatically builds, tests and publishes code for a project — can therefore taint every package that runner is allowed to publish. It also searches a developer’s computer for other Node.js projects and copies itself into them, so a single infected install can compromise an entire workstation.

“If any of the affected packages ran in your environment, treat the machine or runner as exposed until secrets are rotated, persistence artifacts are removed, and recent publish activity has been reviewed,” Aikido Security researchers wrote in a blog post. 

Removing the package is not enough

Researchers found that a standard dependency rollback leaves the attacker’s access intact. The malware embeds backdoors in developer tool settings — notably .vscode/tasks.json and .claude/settings.json — which remain on disk even after the npm package is removed. Those files must be audited and cleaned to eliminate the attacker’s foothold.

The payload also installs OS-level background services: a systemd user service on Linux, a LaunchAgent on macOS. Both run a backdoor called kitty-monitor, which polls GitHub’s commit search every hour for signed remote commands. A second process, gh-token-monitor, checks stolen GitHub tokens every 60 seconds — alerting the attacker the moment one is revoked. An attacker can maintain access and monitor the victim’s response in near real time, long after the original infection has been discovered.

Multiple security companies have pointed out which popular dependencies are being targeted. In this wave, it’s been popular data visualization software, including Alibaba’s open-source AntV and TallyUI. The campaign also touched widely used utilities such as echarts-for-react (a React wrapper for ECharts) and timeago.js (a small JavaScript library that allows developers to format timestamps).

“Even if only a subset of those packages received malicious updates, the popularity of the package ecosystem creates meaningful downstream exposure for organizations that automatically pull new dependency versions,” wrote researchers from Socket, an application security company.

The campaign remains active. Because the worm propagates using tokens stolen from infected environments, the number of affected packages is expected to grow. Researchers have warned that any machine or pipeline that installed an affected version should be treated as fully compromised.

Last week, TeamPCP targeted other prominent software libraries with the malware, including TanStack, UiPath, and MistralAI.

The post Mini Shai-Hulud returns, compromising hundreds of npm packages appeared first on CyberScoop.

As defenders get their hands on newer AI models with more powerful cybersecurity capabilities like Anthropic’s Mythos and OpenAI’s Daybreak, organizations are being told to prepare for a flood of new vulnerability reports.

But for bug bounty programs across the nation, that day may already be here, as yesterday’s frontier models and today’s open-source AI tools have dramatically increased the volume of bug reports flowing into companies around their own products or on larger bounty platforms online.

GitHub, one of the world’s largest online code repositories, said it is tightening its definition of a “complete” bug report after a significant increase in AI-assisted submissions over the past year.

Although the influx has had some benefits, many reports are submitted without proof of concept, are reliant on unrealistic attack scenarios or cover issues already listed as ineligible. As a result, the company is having difficulty separating signal from noise.

“This isn’t unique to GitHub,” wrote Jarom Brown, senior product security engineer at GitHub. “Programs across the industry are grappling with the same challenge, and some have shut down entirely.”

Brown said GitHub does not want to ban the use of AI generated reports entirely, calling it a “force multiplier” for security in the right context. But in a world where it’s never been easier to use AI to generate theoretical bugs, the company wants researchers to go the extra mile to confirm that their discoveries can actually be exploited in real-world conditions.

What we need is the same standard we’ve always expected: validation,” Brown wrote. “An AI-assisted finding that’s been verified, reproduced, and submitted with a working proof of concept is a great submission. An unvalidated output submitted as-is without reproduction or demonstrated impact is not.”

Grant Bourzikas, chief security officer at Cloudflare, said triaging bugs and proving they can be exploited  has always been one of the hardest parts of vulnerability research, and AI vulnerability scanners and code have “made it worse.”

For instance, code written in C and C++ programming languages are vulnerable to a range of exploits – like buffer overflows and out-of-bounds reading and writing – that don’t exist in memory safe languages like Rust. AI tools scanning software written in memory unsafe programming languages are far more likely to generate false positives.

But one of the biggest flaws continues to be that AI tools are also designed to give the user what they’re asking for, even when it’s not there. This leads to the generation of bug reports filled with speculation and qualifiers around exploitability that require human follow up.

“That’s a reasonable bias for an exploratory tool,” Bourzikas wrote. “It’s a ruinous one for a triage queue, where every speculative finding spends human attention and tokens to dismiss, and that cost compounds across thousands of findings.”

Cloudflare recently shared results from testing Mythos on 50 of its own code repositories, looking for exploits. Bourzikas called Mythos “a different kind of tool doing a different kind of work” from other frontier models, and that it made significant progress in reducing false positives.

For example, he pointed to two Mythos capabilities that stood out compared to other models: chaining exploits together and generating its own proof-of-concept code to confirm exploitability.

Older models could spot many of the same bugs, but they often couldn’t figure out how to exploit them effectively, or show that the issue could be exploited in real world conditions.

Others have argued that the gap in bug hunting capabilities between newer frontier AI models and older ones, or open source models available today is not as large as advertised. 

Swedish software developer Daniel Stenberg, lead developer for curl, an open source file transfer tool used around the world, recently wrote about his experience with Mythos Preview. Like others, he has also seen a higher volume of AI-fueled bug reports over the past year, but said the flood of low-quality reports has tapered off significantly since March as models have improved.

Curl is mature and polished by the standards of most software: Stenberg estimates each line of code has been rewritten or altered at least four times, and he said he has used both human and AI tools in the past to implement hundreds of bug fixes over Curl’s existence.

That makes it a unique testing ground for the enhanced capabilities of Mythos, which was reportedly so powerful at finding vulnerabilities that Anthropic opted not to release it to the general public.

After gaining access to Mythos, Stenberg received the results of a scan of 178,000 lines of curl code. Ultimately, the scan flagged five “confirmed” vulnerabilities. Further exploration by human researchers found that 4 of the bugs were false positives or had no security impact. The one remaining bug Mythos found? A low-severity flaw that will be fixed in a regular June update.

Even as he praised the impact of AI on cybersecurity generally, Stenberg concluded that for all the hype, Mythos is only “a bit better” than previously released models.

“My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing,” he wrote. “I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos.”

The post AI might cut false positives, but it won’t stop the slop  appeared first on CyberScoop.