You know how we always preach to secure everything: servers, processes, applications? It turns out that a lot of us missed a serious blind spot hiding in plain sight—CI/CD pipelines, particularly in how GitHub Actions workflows are configured. Sysdig’s Threat Research Team (TRT) recently dropped some eye-opening findings, uncovering dangerous vulnerabilities in workflows for major open-source projects like MITRE and Splunk. These issues aren’t just theoretical risks or something “future-you” can deal with. If you’re a Linux admin or developer involved in open-source projects, this is your nudge to take GitHub Actions security seriously—because bad actors already are. . The culprit? Misusing the pull_request_target trigger. It sounds innocent on paper—running workflows in the context of the base branch—but combine it with some lazy configurations, and you’re practically handing over your secrets and permissions to malicious actors. Let me break down exactly how the exploit works and why we need to address it yesterday. The Problem: Misconfiguring pull_request_target Opens Dangerous Doors Here’s the deal. GitHub Actions is a fan favorite for automating CI/CD pipelines , and it’s easy to see why. Integration with repos is smooth, flexible, and clean, eliminating manual grunt work. But flexibility comes at a cost if you don’t know what you’re doing—just ask Sysdig’s researchers. The pull_request_target trigger does something deceptively risky: it runs workflows in the base branch context (like main ) when processing pull requests from forks. That means it can access repository secrets and the high-privilege GITHUB_TOKEN by default. Here’s where things spiral: if your GitHub Action workflow checks out code from a fork’s head.ref (essentially untrusted pull request code from contributors), it opens the door for an attacker. A crafty user can inject malicious payloads—editing files like setup.py (for Python packages), or requirements.txt —and inone sweep, nab sensitive credentials or even escalate privileges across the repository. Think about it; this isn’t a complex exploit. It’s a glaring weakness, and popular open-source repositories are already vulnerable. Who’s a Sitting Duck? Honestly, this affects a lot of folks. Open-source projects with contributors all over the globe? Yep, you’re in the crosshairs. High-profile repositories like MITRE’s Cyber Analytics Repository or Splunk’s security_content ? Directly exposed. And here’s the gut-punch: many developers just don’t realize how dangerous the default high-privilege permissions tied to GITHUB_TOKEN really are. Combine that with the misuse of workflow triggers like pull_request_target , and you’ve got a recipe for repository-wide chaos. Even worse, this issue isn’t limited to the giants. Many smaller projects are equally at risk simply because workflow security isn’t a high priority (or maybe it’s not well-understood). How Do You Fix This? If reading this made you glance nervously at your own GitHub Actions configuration, you’re not alone. The good news? This isn’t rocket science to fix—it’s just a matter of being proactive and following smarter practices. Stop Using pull_request_target Recklessly Here’s the hard truth: if your workflows involve untrusted code (e.g., contributions from forks), avoid using pull_request_target . Instead, stick to pull_request for safety. Why? Unlike its dangerously convenient cousin, pull_request executes workflows against a pull request’s branch context, limiting exposure of secrets and privileged tokens. If you must use pull_request_target for some reason, block workflows from executing on untrusted foreign code. It’s better to inconvenience contributors a little than to jeopardize your whole repo. Clamp Down on GITHUB_TOKEN Permissions GitHub generously sets the GITHUB_TOKEN permissions high by default, which is a disaster waiting to happen. Adjust those privileges in your reposettings; make them read-only unless absolutely necessary. Better yet, use fine-grained personal access tokens for sensitive workflows where you need more control. Rethink Secret Management Here’s a tip: secrets don’t belong everywhere. Limit their scope to the specific workflows or jobs where they’re actually needed. If your repository secrets can be accessed globally, it’s time to rethink that setup. Apply the principle of least privilege like your job depends on it—because one day, it might. Audit Regularly When was the last time you actually audited your workflows ? If the answer is “never,” now’s a good time to start. Look for dangerous patterns like automatic checkout of pull-request branches, and get yourself some help from security-focused tools. Open-source linters designed for GitHub Actions can flag insecure practices before they become leaks. Train and Spread the Word Let’s be honest: GitHub Actions security isn’t exactly everyone’s favorite lunchtime topic. So make it one. Hold internal sessions, show your devs how GITHUB_TOKEN permissions work, and teach them why certain triggers (like pull_request_target ) are time bombs if misconfigured. Wrapping It All Up GitHub Actions is a great tool—until it isn’t. These workflows might not feel as major as your servers, but make no mistake, misconfigurations can lead directly to repository takeovers. And once sensitive credentials or secrets are exposed, it’s game over. The vulnerabilities discovered in repositories like MITRE and Splunk should be a wake-up call for all of us in the Linux and infosec community. This isn’t about being paranoid—it’s about being aware and acting before bad actors do. So if you haven’t already, start digging into your workflows and lock them down. It’s as much a part of your security stack as managing firewalls or deploying access controls . And the longer you wait, the closer attackers get to turning your CI/CD pipelines into their playground. Don’tgive them that chance. . Misconfiguring the pull_request_target trigger leads to serious security risks in GitHub Actions workflows for open-source projects.. GitHub Actions, CI/CD Security, Open Source Risks, Workflow Vulnerabilities, Secure Configurations. . Brittany Day
One of the great longtime features of Ubuntu Linux has been Launchpad's Personal Package Archives (PPAs) for easily augmenting the official Ubuntu repositories with additional packages either to supply updated versions of select software or for software not yet found in the official Ubuntu archives. With Ubuntu 23.10 a change is being made in how PPAs are managed to enhance the security and reliability. . Up to this point Ubuntu PPAs were managed via a .list file within /etc/apt/sources.list.d while a GPG keyring was added within /etc/apt/trusted.gpg.d. Starting with Ubuntu 23.10, PPAs will be managed by deb822-formatted .sources files where the keys are directly embedded into the same file. The intent of reworking how the Ubuntu PPAs are managed on user systems is intended to make it easier to also ensure a PPA's associated key is removed from the system if also removing the PPA from the system. The link for this article located at Phoronix is no longer available. . Explore the advancements in Ubuntu 23.10 that revolutionize PPA handling, leading to improved safety and dependability through innovative file structures.. PPA Management, Ubuntu 23.10, Enhanced Security, Software Repositories. . LinuxSecurity.com Team
Get the latest Linux and open source security news straight to your inbox.