[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f0KIafCpXcWnKK8C-jqPGBU1KFAdCmWHnGW3cDcQXLw0":3},{"article":4,"iocs":46,"watch_terms":47,"solutions":48,"lesson":135},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"url":11,"image_url":12,"published_at":13,"ingested_at":14,"relevance_score":15,"entities":16,"category_id":23,"category":24,"article_tags":28},"30c9c1bd-d818-46a3-9905-592433d2e0f7","GitHub to Block pull_request_target Workflows by Default Starting December 2","github-to-block-pull-request-target-workflows-by-default-starting-december-2-89cbfc","GitHub will begin blocking GitHub Actions workflows triggered by pull_request_target in public repositories on December 2, 2026, expanding its protections against a class of CI\u002FCD vulnerabilities that has repeatedly enabled attackers to steal credentials and compromise open source software releases. The restriction, originally announced in September, will prevent affected workflows from running unless an applicable Actions event policy explicitly allows them. GitHub had initially scheduled enforcement for November 2 but confirmed the postponed December 2 deadline in a new update this week, giving maintainers additional time to review their automation and configure exceptions. The new restriction goes beyond protections introduced in June, when GitHub updated actions\u002Fcheckout to prevent common attempts to check out untrusted pull request code inside privileged workflows. This time, GitHub is blocking the pull_request_target trigger itself by default, including for workflows that use it safely. pull_request_target Is Now a Common Attack Vector Vector # GitHub introduced pull_request_target in 2020 to help maintainers automate tasks involving pull requests from external contributors. Unlike the standard pull_request event, which restricts access to secrets and provides a read-only token for contributions from forks, pull_request_target runs in the context of the base repository with access to its configured secrets and token permissions. That elevated access makes the trigger useful for legitimate maintenance tasks such as assigning reviewers, labeling pull requests, and posting authenticated comments. The workflow definition runs from the repository's trusted default branch, rather than the contributor's proposed changes. The security risk emerges when that privileged workflow checks out and executes code from an untrusted fork or passes attacker-controlled pull request data into shell commands. A malicious contributor can exploit those mistakes to execute commands with access to credentials and other resources intended only for trusted automation. Researchers have warned about these vulnerabilities, commonly called \"pwn requests,\" since at least 2021. Variations of this attack pattern contributed to major supply chain incidents involving Nx, PostHog, and TanStack. GitHub's June changes addressed a common source of these vulnerabilities by making actions\u002Fcheckout reject unsafe fork checkouts in privileged workflows unless explicitly overridden. The December policy takes a broader approach, preventing the event from triggering a workflow at all unless administrators have authorized it through an applicable policy. Two Test Windows Before December Enforcement # GitHub's default restriction currently operates in evaluation mode, allowing affected workflows to continue running before enforcement begins. The company has scheduled two temporary enforcement periods, known as brownouts, to expose configurations that will stop working under the new policy: November 9, 16:00–18:00 UTC November 16, 16:00–18:00 UTC During those windows, blocked pull_request_target attempts will generate failed workflow runs with an error annotation instead of executing. The default policy will return to evaluation mode after each test. On December 2, the restriction becomes permanent for affected public repositories without an applicable policy allowing the event. The change applies to public repositories on GitHub Free, Team, and Enterprise Cloud, but excludes private and internal repositories and GitHub Enterprise Server. Maintainers who still require pull_request_target can create an Actions event policy that explicitly permits it. GitHub supports targeting individual workflow files, allowing administrators to preserve specific automation without enabling the trigger across an entire repository. Existing applicable event policies are not replaced by the new default. Some Open Source Maintainers Face a Complicated Transition # The broader restriction introduces complications for open source projects that have relied on pull_request_target for legitimate automation, sometimes across dozens of repositories. A carefully configured workflow that only labels pull requests or manages project metadata may pose little of the risk GitHub is addressing, but it will still be subject to the new restriction. Maintainers must either allow these workflows explicitly or move them to another trigger where appropriate. There are also differences in the administrative tools available across GitHub's pricing tiers. GitHub's documentation for workflow execution protections describes policy configuration at the repository, organization, and enterprise levels for public repositories, including those on free plans. However, the ability to create policies in evaluation mode is reserved for Enterprise Cloud, where administrators can examine policy insights before turning on enforcement. That disparity had already prompted questions following GitHub's September announcement of the new defaults. In a GitHub Community discussion, open source maintainer George Joseph questioned how smaller organizations were expected to assess the impact without Enterprise policy insights. \"How would us mere mortals who run open-source organizations see what workflows would be affected?\" he asked. A community response suggested manually searching repositories for workflows using pull_request_target, inspecting existing workflow runs, and testing explicit allowlisting policies. These approaches can identify affected configurations, but require additional work from maintainers managing multiple repositories. The December deadline gives projects several more weeks to prepare, while the scheduled brownouts offer a preview of what enforcement will look like. GitHub's decision also represents a significant shift for a feature originally created to make external contributions easier to manage: privileged pull request automation will now require an explicit exception to continue running under the new default.","GitHub is enhancing security by defaulting to block pull_request_target workflows in public repositories starting December 2, 2026. This move aims to mitigate CI\u002FCD vulnerabilities exploited to steal credentials and compromise open-source releases. The restriction will require explicit policy exceptions for workflows that rely on this trigger, which runs with elevated access.","GitHub to block pull_request_target workflows by default in public repos on Dec 2, 2026.","https:\u002F\u002Fsocket.dev\u002Fblog\u002Fgithub-to-block-pull-request-target?utm_medium=feed","https:\u002F\u002Fcdn.sanity.io\u002Fimages\u002Fcgdhsj6q\u002Fproduction\u002F34adb0fa8df2fe073db75712dfab2e7d8faeb54f-1672x941.png?w=1000&q=95&fit=max&auto=format","2026-11-05T15:01:39.11+00:00","2026-11-05T21:00:29.508422+00:00",8,[17,20],{"name":18,"type":19},"GitHub Actions","product",{"name":21,"type":22},"GitHub","vendor","26b0b636-0e31-4db1-bffb-61bdf9f20a58",{"id":23,"icon":25,"name":26,"slug":27},null,"Supply Chain","supply-chain",[29,34,36,41],{"category":30},{"id":31,"icon":25,"name":32,"slug":33},"02371804-cf6d-4449-98de-f1a2d4d9b266","Tools","tools",{"category":35},{"id":23,"icon":25,"name":26,"slug":27},{"category":37},{"id":38,"icon":25,"name":39,"slug":40},"80544778-fabb-4dcd-aa35-17492e5dcf4f","Vulnerabilities","vulnerabilities",{"category":42},{"id":43,"icon":25,"name":44,"slug":45},"c5c77cdb-f7d7-4990-9436-c81dcbff1163","Policy","policy",[],[21,18],{"controls":49,"vendors":129},[50,76,103],{"slug":51,"name":52,"problem":53,"products":54},"breach-attack-simulation","Breach and attack simulation","You only find out whether your security tools stop an attack when a real attacker tries.",[55,63,71],{"vendor_slug":56,"vendor_name":57,"vendor_logo":58,"product_slug":59,"product_name":60,"url":61,"description":62},"pentera","Pentera","\u002Fvendor-logos\u002Fpentera.png","pentera-platform","Pentera Platform","https:\u002F\u002Fpentera.io\u002Fpentera-platform\u002F","Runs automated, safe attacks in production to validate exploitable attack paths, prioritise proven risk and confirm fixes. Modules cover internal networks, the external attack surface and cloud.",{"vendor_slug":64,"vendor_name":65,"vendor_logo":66,"product_slug":67,"product_name":68,"url":69,"description":70},"attackiq","AttackIQ","\u002Fvendor-logos\u002Fattackiq.png","attackiq-ready","AttackIQ Ready","https:\u002F\u002Fwww.attackiq.com\u002Fproducts\u002Fready\u002F","Managed service that runs MITRE ATT&CK based emulations for you, with no scripting or tuning on your side.",{"vendor_slug":64,"vendor_name":65,"vendor_logo":66,"product_slug":72,"product_name":73,"url":74,"description":75},"attackiq-flex","AttackIQ Flex","https:\u002F\u002Fwww.attackiq.com\u002Fproducts\u002Fflex\u002F","Agentless, on-demand testing of security controls without deploying the full platform.",{"slug":77,"name":78,"problem":79,"products":80},"security-awareness-training","Security awareness training and phishing simulation","People recognise and report attacks instead of falling for them.",[81,88,95],{"vendor_slug":82,"vendor_name":83,"vendor_logo":84,"product_slug":77,"product_name":85,"url":86,"description":87},"knowbe4","KnowBe4","\u002Fvendor-logos\u002Fknowbe4.png","KnowBe4 Security Awareness Training","https:\u002F\u002Fwww.knowbe4.com\u002Fproducts\u002Fsecurity-awareness-training","Training library and simulated phishing with reporting.",{"vendor_slug":89,"vendor_name":90,"vendor_logo":91,"product_slug":89,"product_name":92,"url":93,"description":94},"sosafe","SoSafe","\u002Fvendor-logos\u002Fsosafe.png","SoSafe Awareness Platform","https:\u002F\u002Fsosafe-awareness.com\u002F","Behaviour-based awareness training and phishing simulation in many languages.",{"vendor_slug":96,"vendor_name":97,"vendor_logo":98,"product_slug":99,"product_name":100,"url":101,"description":102},"huntress","Huntress","\u002Fvendor-logos\u002Fhuntress.png","managed-sat","Huntress Managed Security Awareness Training","https:\u002F\u002Fwww.huntress.com\u002Fplatform\u002Fsecurity-awareness-training","Security awareness training and phishing simulation, managed for you.",{"slug":104,"name":105,"problem":106,"products":107},"software-supply-chain","Software supply chain security","Malicious and vulnerable open-source packages are caught before they ship.",[108,116,124],{"vendor_slug":109,"vendor_name":110,"vendor_logo":111,"product_slug":112,"product_name":113,"url":114,"description":115},"jfrog","JFrog","\u002Fvendor-logos\u002Fjfrog.png","jfrog-xray","JFrog Xray","https:\u002F\u002Fjfrog.com\u002Fxray\u002F","Software composition analysis and SBOM generation for artifacts.",{"vendor_slug":117,"vendor_name":118,"vendor_logo":119,"product_slug":120,"product_name":121,"url":122,"description":123},"snyk","Snyk","\u002Fvendor-logos\u002Fsnyk.png","snyk-open-source","Snyk Open Source","https:\u002F\u002Fsnyk.io\u002Fproduct\u002Fopen-source-security-management\u002F","Finds and fixes vulnerable open-source dependencies in code and pipelines.",{"vendor_slug":109,"vendor_name":110,"vendor_logo":111,"product_slug":125,"product_name":126,"url":127,"description":128},"jfrog-curation","JFrog Curation","https:\u002F\u002Fjfrog.com\u002Fcuration\u002F","Blocks malicious and risky open-source packages before they enter your repositories.",[130],{"slug":131,"name":21,"logo_path":132,"roles":133},"github","\u002Fvendor-logos\u002Fgithub.png",[134],"reported_by",{"slug":136,"title":137,"body":138,"framework_refs":139,"framework_notes":147},"github-blocks-elevated-cicd-workflows-to-prevent-credential-theft-in-open-source-pipelines","GitHub Blocks Elevated CI\u002FCD Workflows to Prevent Credential Theft in Open-Source Pipelines","The `pull_request_target` workflow trigger runs with elevated repository permissions, including access to secrets, even when triggered by code from untrusted forks — creating a significant attack vector for credential theft and supply chain compromise. Threat actors have exploited this design to inject malicious code into CI\u002FCD pipelines, stealing secrets and corrupting open-source releases consumed by thousands of downstream users. GitHub's decision to block this trigger by default acknowledges that many maintainers were unknowingly running privileged workflows against untrusted contributor code. This matters because CI\u002FCD pipeline compromises have become a primary vector for large-scale supply chain attacks, as a single poisoned pipeline can propagate malicious artifacts broadly. Organizations relying on open-source dependencies must understand that upstream pipeline security directly affects their own software supply chain integrity.",[140,141,142,143,144,145,146],"NIST CSF 2.0 PR.AA: Identity Management, Authentication, and Access Control","CIS Control 7: Continuous Vulnerability Management","ISO\u002FIEC 27001:2022 A.8.8: Management of technical vulnerabilities","NIST SP 800-53 SI-2: Flaw Remediation","OWASP A06:2021 Vulnerable and Outdated Components","NIS2 Article 21(2)(b)","MITRE ATT&CK T1566: Phishing",{"NIS2 Article 21(2)(b)":148,"MITRE ATT&CK T1566: Phishing":149,"NIST SP 800-53 SI-2: Flaw Remediation":150,"OWASP A06:2021 Vulnerable and Outdated Components":151,"CIS Control 7: Continuous Vulnerability Management":152,"ISO\u002FIEC 27001:2022 A.8.8: Management of technical vulnerabilities":153,"NIST CSF 2.0 PR.AA: Identity Management, Authentication, and Access Control":154},"NIS2 requires incident handling and security controls for supply chain risks; exploiting CI\u002FCD pipelines to poison open-source releases is precisely the kind of supply chain attack vector NIS2 mandates organizations defend against.","While not phishing in the traditional sense, attackers abusing `pull_request_target` use a deceptive contribution (a malicious pull request) as the initial lure to execute privileged code — mirroring the social-engineering premise of this ATT&CK technique within a CI\u002FCD context.","GitHub's default-block policy is itself a flaw remediation action; organizations should have their own processes to identify and correct insecure pipeline configurations without waiting for a platform-enforced change.","Downstream consumers of open-source packages built through compromised pipelines are directly exposed to supply chain risk stemming from vulnerable or tampered components introduced during the CI\u002FCD build process.","The dangerous behavior of `pull_request_target` has been publicly documented for years; continuous assessment of pipeline configurations would have identified and remediated this misconfiguration before exploitation.","Failure to review and restrict a known high-risk CI\u002FCD trigger represents an unmanaged technical vulnerability in the software development environment that this control requires organizations to track and remediate.","The core vulnerability is a workflow trigger running with elevated privileges against untrusted code; enforcing least-privilege access controls on CI\u002FCD identities and secrets directly addresses this risk."]