Opensource

Blogs Security Advisory

Open Source Developers are Targeted in an active Social Engineering Campaign via Slack

Threat Actors impersonating as Linux Foundation leader in an active social engineering campaign targeting open source developers via Slack.

Now, a fresh Open Source Security Foundation (OpenSSF) advisory warns unknown attackers are using a similar approach to target other open source developers.

The human connection has been leveraged to target software.

The attackers interacted via Slack or social media platform LinkedIn, posing as company owners/representatives, job recruiters, or podcast hosts, and tried to lure developers into downloading malware mimicking as a videoconferencing software update, a type of phishing campaign.

Key facts

  • Attackers impersonated a Linux Foundation leader in Slack to target open source developers.
  • Victims were tricked into entering credentials and installing a malicious “Google certificate.”
  • The phishing campaign used AI-themed lures and legitimate services like Google Sites to appear credible.
  • Attack techniques varied by operating system, enabling interception of encrypted traffic on both macOS and Windows.
  • Security experts urge developers to verify identities and avoid installing unsolicited certificates or running unknown scripts.

Crafting of attack via social engineering

First step, attackers began with a scheming social engineering ploy

They joined Slack workspaces linked to the Linux Foundation’s TODO Group and then imitated a trusted community figure and sent direct messages to developers which looked like any legitimate invite – complete with a Google Sites link, fake email address and exclusive “access key” – to test a purported AI tool for predicting open source contribution acceptance.

Second step, once a victim clicked, they landed on a phishing page impersonating a Slack workspace invitation, prompting them to enter their email and a verification code. Instructions came in form to install what was described as a “Google certificate” from attackers side.

This was basically a malicious root certificate that allowed attackers the ability to intercept and read encrypted traffic – a devastating breach of privacy and security.

The attack module is sophisticated did not end there.

Consecutively on macOS, a script silently downloaded and executed a binary called “gapi,” potentially opening the door to full system compromise.

Windows users faced a browser-based certificate installation, equally effective at undermining secure communications. The attackers’ use of trusted infrastructure such as Google Sites allowed them to evade basic security checks and blend in with legitimate traffic.

Changing attack scenario in social engineering

Now open sources developers have become prime targets, with recent campaigns also hitting maintainers of projects like Fastify, Lodash, and Node.js.

Posing as the Linux Foundation leader, the attacker described how an AI tool can analyze open source project dynamics and predict which code contributions .

The attack was first brought to public attention on April 7, 2026, posted to the OpenSSF Siren mailing list by Christopher “CRob” Robinson, Chief Technology Officer and Chief Security Architect at the Open Source Security Foundation (OpenSSF).

Focus Shift from code repositories to human connections

Attackers now confidently targeting not only code repositories and networks that expanded over trust, but exploiting the personal trust networks that underpin open source collaboration. The expansion of open source ecosystem reminds to be more vigilant as attackers are evolving tactics and developers must now defend code and connections both.

The OpenSSF advisory :

The OpenSSF urges heightened vigilance: always verify identities through separate channels, never install certificates from untrusted sources, and treat unexpected security prompts with skepticism. If compromise is suspected, immediate network isolation and credential rotation are critical.

Sources: Social engineering attacks on open source developers are escalating – Help Net Security

Blogs Cybersecurity News

Scanners Turn Attack Vector as TrivyScanner Hijacked via GitHub Actions Tags

Attackers Targeted SSH keys, Cloud Tokens & API secrets in CI/CD Pipelines; Highlights Securing CI/CD Pipelines

In latest vulnerability discovery Aqua Security revealed HackerBot-claw bot hijacked 75 of 76 GitHub Actions tags for its Trivy vulnerability scanner. The HackerBot-claw first distributed credential-stealing malware through the widely used security tool for the second time in a one month.

Malicious code rode alongside legitimate scans, targeting SSH keys, cloud tokens and API secrets in CI/CD pipelines. Security researcher Paul McCarty was the first to warn publicly that Trivy version 0.69.4 had been backdoored, with malicious container images and GitHub releases published to users.

Attack module on Trivy

When it comes to workflow it has been observed that more then 10,000 GitHub workflow files rely on trivy-action. Attackers can leverage this pipeline and pull versions during the attack window which are affected and carry sensitive credentials exfiltrated.

Attackers compromised the GitHub Action by modifying its code and retroactively updating version tags to reference a malicious commit. This permitted data used in CI/CD workflows to be printed in GitHub Actions build logs and finally leaking credentials.

A self-propagating npm worm compromised 47 packages, extending the blast radius into the broader JavaScript ecosystem.

Aqua Security disclosed in a GitHub Discussion that the incident stemmed from incomplete containment of an earlier March 1 breach involving a hackerbot-claw bot.

  • Attackers swapped the entrypoint.sh in Trivy’s GitHub Actions with a 204-line script that prepended credential-stealing code before the legitimate scanner.
  • Lines 4 through 105 contained the infostealer payload, while lines 106 through 204 ran Trivy as normal.
  • This made difficult  to detect during routine scans.

TeamPCP preserved normal scan functionality to avoid triggering CI/CD failures as detection now will require cryptographic verification of commit signatures .

For defenders, traditional CI/CD monitoring, which watches for build failures or unexpected output, can no longer catch supply-chain compromises that deliberately maintain normal behavior.

Organizations relying on Trivy or similar open-source security tools are facing attacks from the very scanners meant to protect their pipelines can become the attack vector. Only cryptographic provenance checks can distinguish legitimate releases from poisoned ones.

As per security researchers once inside a pipeline, the malicious script scanned memory regions of the GitHub Actions Runner.

Github Compromise

The attack appears to have been accomplished via the compromise of the cx-plugins-releases (GitHub ID 225848595) service account, as that is the identity involved in publishing the malicious tags. 

Credentials exfiltrated during the initial incident were used last week in a new supply chain attack that targeted not only the Trivy package but also trivy-action and setup-trivy, Trivy’s maintainers have confirmed in a March 21 advisory.

Key Findings b Wiz Research

  • According to Wiz, the attack appears to have been carried out via the compromise of the “cx-plugins-releases” service account, with the attackers with malicious container images and GitHub releases published to users.
  • The second stage extension is activated and the malicious payload checks whether the victim has credentials from cloud service providers such as GitHub, AWS, Google Cloud, and Microsoft Azure.
  • When credentials if they are detected, it proceeds to fetch a next-stage payload from the same domain (“checkmarx[.]zone”).

“The payload attempts execution via npx, bunx, pnpx, or yarn dlx. This covers major JavaScript package managers,” Wiz researchers Rami McCarthy, James Haughom, and Benjamin Read said. “The retrieved package contains a comprehensive credential stealer.

Harvested credentials are then encrypted, using the keys as elsewhere in this campaign, and exfiltrated to ‘checkmarx[.]zone/vsx’ as tpcp.tar.gz.”

Conclusion: Aqua Security urged affected users to “treat all pipeline secrets as compromised and rotate immediately.” 

Organizations that ran any version of trivy-action, setup-trivy, or Trivy v0.69.4 during the attack window should audit their CI/CD logs for unexpected network connections to scan.aquasecurtiy[.]org and check whether any tpcp-docs repositories were created under their GitHub accounts.

With three major tag-hijacking incidents in 12 months, Wiz security researcher Rami McCarthy recommended that organizations “pin GitHub Actions to full SHA hashes, not version tags.”

Sources: Trivy Breached Twice in a Month via GitHub Actions

Scroll to top