Connect with us

CyberSecurity

What Changes When Your Software Supply Chain Includes AI Writing Your Code?

Published

on

AI code supply chain

The Old Problem Was Hard Enough

For the better part of a decade, “software supply chain security” meant one thing: tracking what’s inside your code. Which open-source packages. Which versions. Which transitive dependencies three layers deep that nobody consciously chose.

SolarWinds, Log4Shell, and XZ Utils all taught the same bitter lesson. The risk lives less in the code a team writes itself, and more in the millions of lines they pull in from strangers on the internet. Locking down that pipeline became an industry obsession.

Then AI joined the build. And the question got a lot messier.

AI Doesn’t Just Help You Code — It Becomes a Dependency

When a developer pastes a prompt into GitHub Copilot or OpenAI‘s ChatGPT and accepts a suggestion, that snippet enters the codebase like any other contribution. But it’s fundamentally different from a line written by a human teammate.

You didn’t interview the model. It doesn’t have a security clearance. It doesn’t know your threat model. And critically, you have almost no visibility into the data it was trained on — which means you can’t audit whether that suggested function contains logic lifted from a GPL-licensed project, or worse, a known vulnerability.

This is not theoretical. Studies have shown that AI code assistants can regurgitate verbatim blocks from copyrighted repositories. They also hallucinate package names, suggesting libraries that don’t exist — a perfect vector for dependency confusion attacks.

The Provenance Problem Gets Worse

Traditional supply chain security relies on provenance. You know where a package came from because it has a signed manifest, a checksum, a chain of custody. With AI-generated code, the lineage is opaque. The model is a black box. You can’t ask it, “Where did you learn this algorithm?” and get a verifiable answer.

Some teams are already experimenting with adding AI model identifiers to their software bill of materials (SBOM). But that’s a nascent practice. Most organizations don’t even have a complete SBOM for their human-written dependencies, let alone one that accounts for AI contributions.

Three New Risks You Can’t Ignore

Adding AI to the build pipeline introduces categories of risk that traditional supply chain tools weren’t designed to catch.

  • Invisible backdoors: A model trained on public code may have absorbed intentionally planted vulnerabilities. Researchers have demonstrated “poisoned” training data that causes models to suggest insecure code patterns when triggered by specific prompts. You wouldn’t know unless you tested every suggestion against a known exploit database.
  • License contamination: AI models don’t respect licenses. They train on everything. If a model suggests code that’s functionally identical to a GPL-licensed function, your proprietary project could suddenly have a compliance problem. The legal landscape here is unsettled, but the risk is real.
  • Loss of institutional knowledge: When a human writes a tricky piece of logic, they usually understand why it works. When AI writes it, the developer accepting the suggestion may not fully grasp the implications. The code passes review, but the reasoning behind it doesn’t. That’s a maintenance and security time bomb.

What Security Teams Should Do Right Now

You can’t ban AI code generation — it’s already too widespread. But you can adapt your supply chain practices to account for it.

First, treat every AI-generated code block as a high-risk third-party dependency. Subject it to the same scrutiny you’d give a new open-source library. Run static analysis. Check for known vulnerability patterns. Review it line by line, not just glance at the diff.

Second, update your software supply chain security policy to explicitly address AI contributions. Require that developers tag or comment code that was generated by an AI model. This makes it auditable. It also helps your security team spot patterns — if a particular model keeps suggesting vulnerable code, you can flag it.

Third, push your tooling vendors for transparency. Ask your AI coding assistant provider what data their model was trained on. Ask if they test for vulnerability injection. Demand a model-level SBOM. The market is young enough that customer pressure can shape the roadmap.

Accountability Is the Hardest Question

In traditional software supply chains, there’s a clear chain of accountability. If a package has a vulnerability, the maintainer is responsible. If a developer introduces a bug, the code review process catches it — or the developer owns the fix.

Who owns the bug when AI wrote the code? The developer who accepted the suggestion? The team that trained the model? The vendor who sold the tool? The legal and engineering answers are still being written. But the prudent approach is to assume that accountability ultimately rests with the human who committed the code. That means your review process needs to be robust enough to catch AI-generated mistakes before they reach production.

The software supply chain was already fragile. Adding AI to the mix doesn’t break it — but it does expose new weak points. The teams that acknowledge those weak points early, and build processes around them, will be the ones that don’t get burned when the next SolarWinds-style incident turns out to have an AI origin story.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

CyberSecurity

Suspected Chinese Hackers Target University Email Systems Through Roundcube Vulnerabilities

Published

on

Roundcube exploit universities

A Targeted Assault on Academic Email

A threat group with suspected ties to China has been caught exploiting known vulnerabilities in Roundcube, an open-source webmail platform, to steal login credentials from universities. The campaign specifically hit physics and engineering departments at institutions in the United States and Canada.

The attackers zeroed in on a critical flaw—tracked as CVE-2024-42009 and carrying a CVSS severity score of 9.3 out of 10—that had already been patched by Roundcube developers. That didn’t stop the hackers. They weaponized the bug to siphon usernames and passwords from targeted email accounts, likely aiming to monitor sensitive communications or pivot into deeper network access.

This isn’t a spray-and-pray operation. The choice of departments suggests a deliberate focus on research tied to defense, aerospace, and advanced engineering—fields where intellectual property and classified data often intersect.

How the Roundcube Attack Worked

The exploit chain relied on a stored cross-site scripting (XSS) vulnerability in Roundcube’s handling of SVG (Scalable Vector Graphics) attachments. By sending a specially crafted email containing a malicious SVG file, the attacker could execute arbitrary JavaScript in the victim’s browser when the message was viewed.

Once the script ran, it could:

  • Capture session cookies and authentication tokens.
  • Redirect the user to a fake login page that harvested credentials.
  • Exfiltrate the stolen data to an attacker-controlled server.

The flaw, discovered and reported by security researchers at SonarSource in July 2024, was patched in Roundcube version 1.6.8 and 1.5.8. Yet many university IT departments, often stretched thin, had not applied the update in time.

CVE-2024-42009: A Critical Weakness

CVE-2024-42009 is a classic case of insufficient input sanitization. Roundcube failed to properly filter SVG elements within HTML emails, allowing attackers to inject JavaScript that the browser would trust as part of the same origin. No user interaction beyond opening the email was required—a dangerous combination.

The CVSS 9.3 rating reflects the ease of exploitation and the potential for complete compromise of email accounts. For universities, the stakes are high: compromised email can lead to leaked grant proposals, unpublished research, and even credentials for adjacent systems like VPNs or internal file servers.

Why Universities Are Prime Targets for Espionage

Academic institutions have long been a soft target for state-sponsored hackers. Their networks are open by design—meant for collaboration and data sharing—but often lack the cybersecurity budgets of government agencies or private corporations.

Physics and engineering departments are particularly attractive. They host cutting-edge research in quantum computing, artificial intelligence, propulsion systems, and materials science. A single compromised professor’s inbox could yield months of sensitive correspondence with defense contractors or national labs.

This campaign mirrors earlier operations by groups like APT41 and TA413, which have also targeted academic email systems using webmail exploits. The pattern is clear: find a common, internet-facing application, weaponize a known vulnerability, and go after high-value users.

Patch Management Remains a Persistent Problem

The attackers didn’t use a zero-day. They used a bug that had a public fix for weeks. Yet they still found victims. That points to a systemic issue in how organizations—especially universities—handle patch management.

Roundcube is widely deployed because it’s free and relatively simple to run. But many IT teams treat it as a set-it-and-forget-it service. When critical updates arrive, they may sit in a queue for months, especially during summer breaks or semester transitions.

Security experts recommend:

  • Enabling automatic updates for Roundcube where possible.
  • Conducting weekly scans of webmail interfaces for known CVEs.
  • Segmenting email servers from other critical infrastructure.

For universities, the lesson is harsh but straightforward: a patched vulnerability is only effective if you actually apply the patch.

Implications for Broader Cybersecurity

This campaign is a reminder that threat actors don’t need sophisticated tools to breach well-funded targets. They just need a single unpatched system and a bit of patience.

For organizations relying on open-source software like Roundcube, the burden of security falls squarely on the operator. The developer community can fix bugs, but they can’t force users to install updates. That gap—between disclosure and deployment—is where attackers live.

As geopolitical tensions continue to drive cyber espionage, universities should expect more of these targeted campaigns. The best defense remains the simplest: patch early, patch often, and assume someone is already trying to get in.

Continue Reading

CyberSecurity

Armored Likho APT: A New Threat to Government and Electric Power Networks

Published

on

Armored Likho APT

A previously undocumented advanced persistent threat (APT) group has been quietly breaching government agencies and electric power providers across at least three countries. Dubbed Armored Likho APT by researchers at Kaspersky, the actor blends financial theft with espionage, using a flexible toolkit that evolves on the fly.

Armored Likho’s operations stretch from Russia to Brazil and Kazakhstan. The group targets both individuals, for monetary gain, and larger organizations, for intelligence. Its arsenal includes modular remote access trojans (RATs) and information stealers, most notably a Python-based payload Kaspersky tracks as BusySnake Stealer.

This isn’t a one-trick pony. The malware stack allows the attackers to maintain stealthy control over compromised machines, siphon credentials, and deploy additional modules tailored to each victim. Kaspersky’s analysis, published in early July 2026, details how the group achieves this with surprising agility.

How Armored Likho Gets In

The primary entry vector is spear-phishing. Emails carry archives containing executable files or LNK shortcuts. When a target opens the attachment, a decoy document appears on screen. Behind the scenes, the real payload installs silently.

One loader, injected directly into memory, was observed fetching additional archives from public GitHub repositories. Those repos held early development builds and test samples. Another method uses LNK files that pull down a full Python 3.12 interpreter and a malicious archive while displaying a fake document to the user.

BusySnake Stealer: The Core Weapon

The centerpiece of Armored Likho’s toolset is BusySnake Stealer, a Python-based infostealer packed with evasion tricks. It decrypts bytecode only when a specific function is called, then re-encrypts it immediately after execution. The process runs without a console window, keeping it out of sight.

BusySnake relies on multiple handlers for different tasks. These include clipboard theft, file enumeration, extraction of 64-character hexadecimal keys, document exfiltration, screenshot capture and archiving, persistence checks, and general command execution.

Commands from the C&C server can trigger a wide range of actions: capturing screenshots, exfiltrating logged keystrokes, decrypting stored passwords from Chromium-based and Firefox browsers, stealing cookies, scraping the machine for OTP keys, locating cryptocurrency wallets, harvesting Telegram sessions and credentials, establishing a reverse SSH tunnel, or even restarting RustDesk to capture user credentials.

From Go2Tunnel to Full Control

Earlier campaigns relied on a separate tool called Go2Tunnel to set up reverse SSH tunnels. Armored Likho has since folded that capability directly into BusySnake Stealer. The infostealer now provides persistent remote access and interactive control over the victim’s system without needing a secondary utility.

Overlap With Eagle Werewolf

Kaspersky notes that Armored Likho’s operations show overlap with a known hacking group called Eagle Werewolf. That group previously used a RAT named AquilaRAT, which shares structural similarities and persistence mechanisms with BusySnake Stealer. The connection suggests the same developers may be behind both toolkits.

The shift toward modular, Python-based malware is a trend worth watching. It gives attackers the flexibility to swap components quickly and evade signature-based detection. For defenders in the government and electric power sectors, this means staying ahead of an adversary that adapts its code as easily as it changes its targets.

As Armored Likho continues to refine its methods, organizations should prioritize email security, monitor for unusual GitHub repository access, and keep an eye out for the telltale signs of BusySnake Stealer deployment.

Continue Reading

CyberSecurity

Citrix NetScaler Memory Leak Under Active Attack — PoC Published

Published

on

Citrix NetScaler flaw

Another Citrix Flaw, Another Race to Patch

It didn’t take long. Just hours after security researchers published a working proof-of-concept exploit for a newly disclosed memory disclosure vulnerability in Citrix’s NetScaler products, attackers began scanning the internet for exposed appliances. The flaw, tracked as CVE-2023-4966 but already being called “CitrixBleed 2.0” by some in the infosec community, lets an unauthenticated attacker read sensitive memory contents — including session tokens and other credentials — from a vulnerable Citrix NetScaler ADC or Gateway appliance.

The timing is brutal. This comes just over a year after the original CitrixBleed vulnerability (CVE-2023-3519) was exploited en masse by ransomware groups. Now, defenders are once again scrambling to assess exposure and apply fixes before the damage spreads.

What the NetScaler Memory Leak Actually Exposes

This isn’t your run-of-the-mill denial-of-service bug. The vulnerability resides in the NetScaler’s handling of HTTP requests. By sending a specially crafted, unauthenticated request, an attacker can trick the appliance into disclosing chunks of its memory. That memory can contain session cookies, authentication tokens, and other sensitive data that would let an adversary hijack active user sessions or escalate privileges.

According to the advisory from Citrix’s security team, the flaw affects multiple versions of NetScaler ADC and NetScaler Gateway — both as standalone appliances and as cloud-delivered services. The company has released updated firmware builds for all supported versions. If your appliance is still on an unsupported version, you’re out of luck: no patch is coming.

PoC Goes Public, Exploitation Follows Immediately

What makes this incident particularly worrying is the speed of the response — from the attacker side. Researchers at Assetnote published a detailed write-up along with a proof-of-concept exploit on October 25. Within 24 hours, multiple threat intelligence firms reported a sharp uptick in scanning traffic targeting NetScaler management interfaces and gateway endpoints.

“We observed a significant increase in probes against port 443 on NetScaler IPs almost immediately after the PoC was released,” said one analyst who asked not to be named due to company policy. “Attackers are automating the exploit and incorporating it into their toolkits.”

The race is now on. For every organization that patches quickly, there’s another that drags its feet — and those are the ones that will get hit.

Who’s at Risk and What to Check Right Now

If your organization runs any of the following, you need to act immediately:

  • NetScaler ADC (formerly Citrix ADC) version 12.1, 13.0, 13.1, or 14.1
  • NetScaler Gateway (formerly Citrix Gateway) on the same versions
  • Citrix Cloud-managed NetScaler instances (patches are applied automatically by Citrix, but verify)

To check if you’ve already been compromised, look for unusual HTTP requests in your NetScaler access logs — specifically, requests with abnormally long headers or repeated patterns that suggest memory probing. Also inspect active sessions: if you see sessions that don’t match known user activity, rotate all credentials immediately.

This vulnerability is a close cousin of the CitrixBleed exploit from 2023, which was used by the LockBit and Clop ransomware gangs to breach hundreds of organizations. The same playbook applies here: patch now, audit later.

Patching and Mitigation: No Workarounds, Only Fixes

Citrix has confirmed there are no viable workarounds for this flaw. The only fix is to update to the patched versions listed in the security bulletin. If you cannot patch immediately, the company recommends restricting access to the NetScaler management interface to trusted IPs only — but that’s a Band-Aid, not a cure.

Here are the patched versions:

  • NetScaler ADC 14.1 build 4.13 and later
  • NetScaler ADC 13.1 build 51.15 and later
  • NetScaler ADC 13.0 build 92.21 and later
  • NetScaler ADC 12.1 build 55.302 and later (if still supported)

For organizations using NetScaler in high-availability pairs, Citrix recommends updating the secondary node first, then failing over and updating the primary. This minimizes downtime but should be done with caution — test the patch in a staging environment if possible.

Lessons from CitrixBleed: History Repeats Itself

The original CitrixBleed vulnerability taught the security community a painful lesson: attackers move faster than most IT teams. In 2023, the exploit was used in the wild for weeks before a patch was even available. This time, the patch came first — but the PoC followed almost immediately, and exploitation began within hours.

“The window between patch release and mass exploitation is shrinking,” said a senior incident responder at a major cybersecurity firm. “Organizations that treat patching as a quarterly task are going to get burned.”

The takeaway is stark: if you run NetScaler, drop everything and patch. If you don’t, you’re gambling with your network’s security — and the house always wins.

Continue Reading

Trending