Hello FastGPT Security Team,

I am reporting a potential GitHub Actions CI/CD security issue affecting the current labring/FastGPT repository.

I did not run this against FastGPT infrastructure, access secrets, push images, deploy to Kubernetes, or perform destructive testing. This report is based on static verification of the current workflows and the original confirmed source-to-sink findings.

Summary

Affected repository:

labring/FastGPT

Checked branch and commit:

main @ 22ebfacbb43311e9b73294040ae0eb87390c6bba

Affected current workflow pairs:

1. Documentation preview image/deployment flow:

   • .github/workflows/preview-docs-build.yml
   • .github/workflows/preview-docs-push.yml

2. FastGPT preview image flow:

   • .github/workflows/preview-fastgpt-build.yml
   • .github/workflows/preview-fastgpt-push.yml

The original vulnerable workflows have been removed:

• .github/workflows/docs-preview.yml
• .github/workflows/fastgpt-preview-image.yml

However, the replacement design still appears to allow artifacts built from untrusted pull request code to cross into privileged workflow_run jobs that have registry push, PR/issue write, attestation, and deployment capabilities.

This report is intentionally conservative: I am not claiming that the original pull_request_target direct execution chain still exists. The current issue is a changed but still security-relevant trust-boundary problem: untrusted PR-built artifacts can be promoted by privileged follow-up workflows.

Current chain 1: docs preview build artifact to privileged deploy

The current documentation preview flow is split into:

• preview-docs-build.yml: low-privilege PR build workflow;
• preview-docs-push.yml: privileged workflow_run push/deploy workflow.

The build workflow still checks out pull request code and builds the documentation Docker image from the PR-controlled document/ tree. The push workflow later downloads the artifact from that workflow run and performs privileged operations.

The privileged sink includes:

• artifact download using secrets.GITHUB_TOKEN;
• GHCR login / image push using GITHUB_TOKEN;
• Kubernetes deployment using secrets.KUBE_CONFIG_CN;
• PR/issue comment capability.

Security-relevant capabilities observed in the push workflow include:

packages: write
attestations: write
id-token: write
pull-requests: write
issues: write
actions: read

The sensitive deployment capability is especially important:

KUBE_CONFIG_CN

This means an image derived from untrusted PR-controlled code can potentially be loaded, tagged, pushed, and deployed by a privileged workflow.

Current chain 2: FastGPT preview image artifact to privileged GHCR push

The current FastGPT preview image flow is also split into:

• preview-fastgpt-build.yml: PR build workflow;
• preview-fastgpt-push.yml: privileged workflow_run push workflow.

The PR build workflow builds Docker image artifacts from pull request code without pushing them directly. The follow-up workflow_run workflow then downloads the artifact, logs in to GHCR using GITHUB_TOKEN, and pushes the image.

The privileged sink has:

• packages: write;
• attestations: write;
• pull-requests: write;
• issues: write;
• actions: read;
• GHCR login using secrets.GITHUB_TOKEN;
• artifact download from the upstream run.

The core risk is that attacker-influenced build artifacts may become trusted registry artifacts.

Security impact

This report does not rely on direct secret exfiltration from the low-privilege build job.

The impact is based on artifact trust-boundary violation:

1. untrusted PR code controls the Docker build context and image contents;
2. the resulting image artifact is uploaded by the PR workflow;
3. a privileged workflow_run workflow downloads that artifact;
4. the privileged workflow pushes the image to GHCR and, for docs preview, deploys it using Kubernetes credentials;
5. the pushed/deployed artifact is then treated as repository-controlled preview infrastructure output.

Potential impact includes:

• publishing attacker-controlled preview images to a repository-controlled container registry;
• deploying attacker-controlled documentation preview images to a Kubernetes environment;
• poisoning trusted preview artifacts and PR automation output;
• misuse of packages: write / registry push capability through untrusted artifacts;
• possible impact on Kubernetes preview infrastructure, depending on runtime isolation and cluster configuration.

I am not reporting the old ALI_IMAGE_NAME PR comment leakage issue because the current workflow appears to have removed that secret-to-comment path.

Non-destructive maintainer-side validation

Please validate only in a controlled test repository, temporary branch, or isolated preview environment. Do not use production Kubernetes credentials or production registry namespaces.

Suggested validation:

1. Create a controlled fork PR that changes only a harmless marker inside the Docker image build context.

2. Ensure the marker is visible only as a fixed string, for example:

FASTGPT_PREVIEW_ARTIFACT_SECURITY_TEST_MARKER

3. Confirm that the pull request build workflow builds an image artifact containing the marker.

4. Confirm that the privileged workflow_run workflow downloads the artifact from the PR run.

5. Confirm whether the privileged workflow:

   • loads the PR-built image artifact;
   • tags it;
   • pushes it to GHCR;
   • for docs preview, deploys it using the Kubernetes preview deployment path.

6. Use temporary test credentials or disable the final push/deploy step during validation.

Expected vulnerable behavior:

• an image artifact derived from fork PR code is accepted by the privileged workflow_run;
• the privileged workflow pushes or deploys that artifact;
• no trusted-actor gate, maintainer approval, artifact provenance validation, or source-origin restriction blocks the path.

Expected safe behavior:

• artifacts from untrusted fork PRs are not promoted by privileged workflows;
• push/deploy workflows run only for trusted actors or trusted branches;
• privileged workflows rebuild from trusted code or verify artifact provenance before promotion;
• Kubernetes and registry credentials are not used on artifacts produced by untrusted PR code.

Suggested remediation

1. Do not promote artifacts built from untrusted fork PR code in a privileged workflow_run job.

2. Add a trusted-origin gate before any push/deploy action. For example, require:

   • same-repository PR;
   • trusted actor association;
   • maintainer-approved label;
   • protected environment approval;
   • or manual workflow dispatch by a maintainer.

3. Rebuild deployable images in the privileged workflow from trusted base-branch code, rather than loading PR-produced artifacts.

4. If preview images for external PRs are required, push them only to an isolated non-production registry namespace using low-privilege credentials.

5. Do not deploy untrusted PR-built images into Kubernetes clusters with meaningful privileges or network access.

6. Bind artifacts strictly to the expected workflow run, repository, event type, commit SHA, and actor; reject artifacts from fork PR runs unless explicitly approved.

7. Validate artifact provenance before docker load, docker tag, docker push, or kubectl set image.

8. Separate untrusted build and trusted deployment:

   • untrusted PR workflow: no secrets, no registry push, no deployment;
   • trusted deployment workflow: only trusted inputs, protected environment, minimal credentials.

9. Scope KUBE_CONFIG_CN and GHCR credentials to the minimum required permissions and rotate them if untrusted preview artifacts have already been promoted.

Please let me know if you need additional static evidence, a shorter reproduction summary, or a maintainer-side validation checklist.