Researchers said they used Anthropic’s Claude and OpenAI’s Codex to identify a damaging flaw embedded in a popular software decoding tool that could leave major internet platforms, enterprise services, and web frameworks vulnerable to data theft and remote access.

The vulnerability, nicknamed HEIF Heist, refers to the malware’s ability to trigger memory corruption errors in affected software, allowing the attacker to pilfer sensitive data from its victims. In a report published Thursday, the researchers laid out the potential damage an attacker could cause, including gaining access to internal OpenAI repositories, leaking user files, access tokens, and other sensitive data for online services like Amazon Web Services, and gaining remote code execution privileges across a range of online services, including Meta’s core product suite, GitHub Enterprise servers and open-source internet forum Discourse.

“Even when Remote Code Execution isn’t immediately achievable, the attack primitives may still allow arbitrary heap disclosure, letting an attacker ‘heist’ in-memory data such as other users’ data and environment variables,” wrote Hacktron researchers Harsh Jaiswal, Mohan SRK, Rahul Maini and Sudhanshu Rajbhar.

The researchers relied heavily on AI systems, including frontier models from OpenAI and Anthropic, to conduct their research. Attribution for the research is described as being “led” by the Hacktron human researchers “assisted by Hacktron Harness, GPT-5.6 Sol, and Opus 5.”

According to the research, the attack exploited the way that code parsing tools in many popular software decoders — specifically libheif and libde265, used to parse C and C++ software — process certain image files.

By uploading HEIF, HEIC and AVIF image files corrupted with malicious code, the attacker could bypass most of the victim’s application layer defenses, in many cases achieving remote code execution privileges for accounts or products tied to major AI and tech brands.   

While the latest version of libheif has been patched, the researchers said “any deployment lacking the latest upstream security patches is potentially vulnerable.”

In one incident detailed in a Sept. 13 blog, Jaiswal, Maini, and Hacktron researcher Mohan Pedhapati described how chaining two vulnerabilities, including an image parser flaw, could compromise OpenAI employee accounts.

With access to the compromised accounts, researchers could reach OpenAI’s internal repositories. As a proof of concept, they opened a pull request in the company’s “monorepo,” a centralized library where code is shared across projects, using the employee’s Codex credentials. 

According to a timeline provided by the researchers, the flaw was discovered on July 25 and patched within days. They said the entire attack, from discovering the initial vulnerability to gaining access to the repositories, took less than 72 hours. OpenAI paid them a bug bounty of $6,500 for their work.

Given that AI models are increasingly integrated into enterprise and personal networks, an attacker exploiting HEIF Heist could have accessed far more than just OpenAI’s systems and data.

“Until two months ago, a user or OpenAI employee logging into OpenAI’s own help forum could have had their ChatGPT and Codex accounts taken over,” the researchers wrote. “Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.”

CyberScoop has reached out to OpenAI for comment on the research and additional information.

At the same time, the researchers said the attack paths they found were not particularly easy or efficient to exploit.

“Exploitation requires fingerprinting the target version and tailoring the payload images,” the blog stated. “Some of our RCE attempts landed only after thousands of image uploads. That said, an AI agentic approach with a frontier model like GPT-5.6 Sol cut exploit development time down to roughly 1 to 3 days from initial probe to remote RCE. A motivated attacker can convert a vulnerable upload endpoint into RCE or an info leak.”

The post Researchers use AI to find widespread software decoder flaw  appeared first on CyberScoop.

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.

Malware targeting AI coding assistants and software developers’ automated workflows is spreading into more environments with more capabilities, placing defenders at a growing disadvantage.

A malware strain dubbed Sandworm_Mode, first discovered by Socket in February, represents a growing threat to software development. According to a CrowdStrike report, the self-propagating worm can spread through code repositories with minimal detection, raising alarms about software supply chains.

The malware’s capabilities are extensive, but not especially unique compared to the series of supply-chain worms known as Shai-Hulud, and more recently Mini Shai-Hulud.

“This is the new trend,” Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, told CyberScoop. “This is something we’re seeing more and more. It’s the new hotness right now.”

Sandworm_Mode targets and steals sensitive data, including credentials, keys and secrets that unlock paths to additional services and dependencies throughout the AI toolchain. This includes AI assistants, cloud providers, API keys for nine major LLM providers, CI/CD pipelines and automated systems that build, test and publish code.

These actions blend in with tens of thousands of other commands occurring daily in any given environment infused with AI development tools. 

“Trying to find the signal of something malicious happening is very difficult because there’s so much noise out there,” Meyers said. 

The worm also paces itself, setting multi-day delays to separate initial access from follow-on malicious activity — creating a gap in victims’ telemetry windows, which makes it even more challenging for defenders to detect and attribute the chain of infection properly. 

“AI agents are pulling down all of these different dependencies continuously throughout the day,” Meyers said. “When you’re looking downrange from the perspective of the security operations team, you’re just seeing everybody pulling down these dependencies, and these dependencies self-unpacking and executing, so it just gets really, really noisy to try to find something bad happening.”

The malware covers its tracks further with a bit of a mean streak, by automatically destroying compromised environments if it can’t spread or accomplish its objectives.

“It’s well thought-through, and well developed, so somebody spent some time caring and feeding this thing,” Meyer said.

Despite CrowdStrike’s four-month review of Sandworm_Mode, the cybersecurity firm has yet to gain a firm handle on its intent, but Meyers said it is designed to attain a strong foothold, which could enable long-term access.

CrowdStrike hasn’t determined who is responsible for the malware, yet Meyers said he doesn’t think TeamPCP, a threat group that’s been on a rampage through open-source software this year, is involved. 

“It could be a nation-state threat actor, or it could be an e-crime actor that’s looking to use this to then sell access to other organizations,” he said. “We don’t really know what the intention is.”

The state of Sandworm_Mode and whether it remains active is also unclear. CrowdStrike said it continues to observe recently active malicious supply-chain packages that follow similar but technically divergent patterns.

Ultimately, “the world has changed,” Meyers said, adding that many attackers are pursuing similar paths in the AI toolchain, requiring defenders and threat hunters to place a greater focus on this burgeoning mode of aggression.

The post Malware is targeting AI tools in software development environments appeared first on CyberScoop.

Cyberstalkers are increasingly exploiting a feature in Google Chrome meant for mobile phone user convenience, but can give intruders broad access to a device owner’s private information, according to researchers.

Certo Software said in a blog post Tuesday that stalkers are making use of Chrome’s sync capability — meant to make it so signing into Chrome on one device makes it easier to do so on other devices, too — to spy on a phone owner’s browsing history and gain access to their stored passwords.

As an illustration, Certo used the case of a pseudonymous victim, Emma, who had searched for a family lawyer and visited a domestic violence support website while her partner was sleeping, only for him to bring up to her two days later.

“Emma had been careful to only ever use her own device, and she hadn’t noticed any new apps appear on her phone,” wrote Certo co-founder Russell Kent-Payne. “What she didn’t know was that weeks earlier, during a few unattended minutes with her phone, he had opened the Chrome app and quietly signed it into a Google account of his own. From that moment on, every site she visited was being copied straight to his account, viewable from any device, anywhere in the world.”

The surveillance is as easy as that: brief access to a phone, signing into a Google account and making sure sync is turned on for that account.

Eva Galperin, director of cybersecurity at the Electronic Frontier Foundation, said on the Bluesky social media app that Certo’s research serves as “an important reminder that tech-enabled abuse isn’t just limited to stalkerware.”

Certo said that Google could do a couple things, such as providing a temporary notification whenever a new account is added or sync is turned on or offering a regular marker to indicate when sync is active and which account it’s syncing to, to protect users.

Google did not respond to multiple requests for comment about Certo’s findings.

But the uptick in usage of that stalking method could be a byproduct of security successes elsewhere in the fight against spyware, Certo said.

“Modern smartphones are harder to compromise than ever. Regular security updates, stricter app store rules, and on-device threat detection have made traditional spyware a much riskier bet for a cyberstalker than it used to be,” Kent-Payne wrote. “As a result, we’re increasingly seeing abusers turn to something far simpler: the legitimate apps already sitting on their victim’s phone. No installation, no suspicious permissions, no telltale battery drain — just a quiet misuse of a feature the victim never knew existed.”

At the same time, Chrome is the world’s most popular browser, and this isn’t the first time security concerns have popped up about its sync feature, among other worries.

The post Security researchers find stalkers abusing Chrome’s sync feature appeared first on CyberScoop.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.