A malicious version of the Checkmarx AST plugin was published to the Jenkins Marketplace — meaning any organization with automatic plugin updates may have pulled attacker-controlled code directly into their CI/CD build environment. That is the headline, but today’s brief also covers a CVSS 9.1 memory leak in 300K+ internet-facing Ollama AI servers, SailPoint’s GitHub repository breach, and two Linux kernel zero-days with possible in-the-wild exploitation.

In the News

Checkmarx Jenkins AST Plugin Compromised in Supply Chain Attack

A malicious version of the Checkmarx AST Jenkins plugin was published to the official Jenkins Marketplace. The attack targeted the plugin distribution channel rather than Checkmarx’s own infrastructure — an approach that bypasses internal code review gates entirely. Jenkins instances configured for automatic plugin updates are the primary concern: they would have pulled the compromised artifact into build pipelines without human review.

The mechanism is straightforward and well-understood in software supply chain taxonomy. The attacker gained the ability to publish to the Marketplace, injected malicious functionality into the plugin package, and relied on the trust relationship between Jenkins and its plugin ecosystem to distribute the payload. This is the same class of attack that hit SolarWinds Orion and Codecov’s Bash Uploader — but scoped to the CI/CD tooling layer where security scanning tools themselves become the vector.

Organizations running the Checkmarx AST plugin should audit their installed plugin version against the known-good hash published by Checkmarx, review build logs for unexpected outbound network connections during or after plugin execution, and rotate any secrets accessible to the Jenkins build environment.

What defenders should do: Verify the integrity of your installed Checkmarx AST plugin version immediately. Audit Jenkins build logs for anomalous network activity. Implement plugin allowlisting and version pinning — automatic updates for CI/CD plugins trade convenience for supply chain risk. Map to MITRE ATT&CK T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain.

Source: SecurityWeek

CVE-2026-7482: Ollama ‘Bleeding Llama’ Exposes 300K+ AI Inference Servers

CVE-2026-7482 is a CVSS 9.1 out-of-bounds read vulnerability in Ollama, the open-source server used to run large language models locally. Dubbed “Bleeding Llama” — a nod to 2014’s Heartbleed — the flaw allows a remote, unauthenticated attacker to trigger a memory leak from the Ollama process. Leaked memory may contain API keys, model parameters, inference session data, and any other content held in the server’s address space.

The attack surface is significant. Over 300,000 Ollama instances are internet-facing according to Shodan data. Ollama runs with no authentication by default, which means most of these servers accept arbitrary requests from any source. The vulnerability does not require any credentials or prior access — it is a single unauthenticated request that triggers the read.

The proliferation of self-hosted AI inference infrastructure is outpacing security team visibility. Many Ollama deployments were stood up by data science or engineering teams without security review, running on default configurations on cloud VMs or edge hardware with direct internet exposure.

What defenders should do: Patch Ollama to the latest version. Identify all Ollama instances in your environment using asset discovery and port scanning (default port 11434). Segment AI inference workloads behind authentication and remove internet-facing exposure. This is fundamentally an exposure management and network segmentation problem. Map to MITRE ATT&CK T1190 — Exploit Public-Facing Application.

Source: The Hacker News

SailPoint Discloses GitHub Repository Breach — No Customer Data Exposed

Identity governance vendor SailPoint disclosed that an attacker gained unauthorized access to one of its GitHub repositories on April 20, 2026. The company states that no customer production data was exposed and that the compromised repository did not contain customer environments or production infrastructure. SailPoint has rotated credentials and engaged external incident response.

The incident is notable not for its direct impact — which appears limited — but for what it signals about developer environment security at identity vendors. When an identity governance and administration (IGA) platform vendor’s development infrastructure is breached, every customer should ask: what secrets were stored in that repository? Were any code signing keys, API tokens, or deployment credentials exposed? Could a modified commit propagate into a future product release?

SailPoint’s public disclosure is the right move. But the broader conversation is about vendor trust and compensating controls. Customers who rely on a single identity provider without independent authentication enforcement points or build artifact verification are carrying unhedged vendor risk.

What defenders should do: If you are a SailPoint customer, confirm with your account team that no artifacts from the compromised repository were distributed to production. Review your own GitHub and development environment hygiene — secrets scanning, branch protection, and commit signing. Ensure your identity architecture does not create a single point of failure at any one vendor. Map to MITRE ATT&CK T1213.003 — Data from Information Repositories: Code Repositories.

Source: SecurityWeek

Linux Kernel ‘Dirty Frag’ Zero-Days — CVE-2026-43284 and CVE-2026-43500 Possibly Exploited in the Wild

Two Linux kernel privilege escalation vulnerabilities — tracked as CVE-2026-43284 and CVE-2026-43500, collectively dubbed “Dirty Frag” (also called “Copy Fail 2”) — were disclosed with reports of possible in-the-wild exploitation. No patches were available at the time of disclosure, making these effectively zero-day conditions for all major Linux distributions.

The blast radius extends beyond standard Linux servers. Linux-based network appliances — next-generation firewalls, network detection and response sensors, DNS resolvers, and cloud infrastructure components — all run kernels affected by these flaws. Any local user who can execute code on an affected system can escalate to root.

What defenders should do: Monitor your Linux distribution vendor’s security advisory channels for emergency kernel patches. Where patches are not yet available, restrict local user access to critical Linux hosts. Audit which network appliances in your environment run Linux kernels and confirm vendor patching timelines. Map to MITRE ATT&CK T1068 — Exploitation for Privilege Escalation.

Source: SecurityWeek

Today’s Deep Dive — Supply Chain Attacks Against CI/CD Plugins

The Checkmarx Jenkins plugin compromise is the latest in a pattern that defenders need to internalize: the tools you trust to secure your pipeline are themselves attack surface.

The Pattern

Supply chain attacks against CI/CD tooling exploit the implicit trust model of plugin ecosystems. Jenkins, GitHub Actions, GitLab CI, and similar platforms allow third-party extensions to execute with the full privileges of the build environment. When an attacker compromises a plugin’s distribution channel — whether through stolen maintainer credentials, a compromised build system, or social engineering of a package registry — the malicious code runs in every pipeline that consumes the update.

This is MITRE ATT&CK T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain. The initial access is not a phishing email or an exploited perimeter service. It is a trusted update from a trusted source, delivered through a trusted channel.

Real-World Precedent

The Codecov Bash Uploader compromise (April 2021) followed an identical pattern: attackers modified a CI/CD tool’s distribution artifact, and every organization that pulled the update leaked environment variables — including secrets, API keys, and credentials — to an attacker-controlled endpoint. The compromise persisted for over two months before detection. The SolarWinds Orion attack (December 2020) operated on the same principle at the software build system level, with a 9-month dwell time across 18,000+ organizations.

The Checkmarx Jenkins incident fits this taxonomy precisely. The target was a security tool, which adds an ironic layer: the application security testing plugin became the initial access vector.

Detection Signals

Detecting supply chain compromise in CI/CD requires monitoring the build environment itself — something most organizations do not treat as a security telemetry source. Key signals include:

  • Unexpected outbound connections from build agents during or immediately after plugin update events
  • Plugin hash mismatches between the installed version and the vendor’s published known-good hash
  • New processes spawned by the plugin that are not part of its documented behavior
  • Credential access patterns from the build agent that do not match the pipeline’s defined scope

In Splunk, correlate Jenkins plugin update logs with network connection events from the same host within a short time window.

Primary Mitigations

  1. Pin plugin versions — do not auto-update CI/CD plugins. Treat every plugin update as a change that requires review.
  2. Verify artifact integrity — compare plugin checksums against vendor-published hashes before deployment.
  3. Segment build environments — build agents should not have unrestricted internet access. Egress filtering limits C2 callback success.
  4. Monitor build agent telemetry — ingest build agent process and network logs into your SIEM. These are high-value hosts.
  5. Maintain a software bill of materials (SBOM) for your CI/CD toolchain — know every plugin, every version, every dependency.

Detection Spotlight

Detect unexpected outbound network connections from Jenkins build agents during or after plugin update events. This Splunk SPL query correlates Jenkins plugin update logs with firewall or proxy connection logs from the same source host within a 5-minute window.

index=jenkins sourcetype=jenkins:log "Updating plugin" OR "Installing plugin"
| eval update_time=_time
| rename host AS jenkins_host
| join type=inner jenkins_host
    [search index=firewall sourcetype=pan:traffic OR sourcetype=cisco:asa action=allowed dest_port!=443 dest_port!=80
    | rename src AS jenkins_host]
| where abs(update_time - _time) < 300
| stats count BY jenkins_host, dest_ip, dest_port, plugin_name
| where count > 0
| sort -count

This query surfaces build agents that made non-standard outbound connections within 5 minutes of a plugin update. Tune dest_port exclusions for your environment. False positives will come from legitimate post-update connectivity checks — baseline normal plugin behavior first, then alert on deviations.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.