Incomplete remediation of fork-status bypass: PullApprove authority is not bound to the trusted GitHub App installation

[blocksifrdev]

Incomplete remediation of fork-status bypass: PullApprove authority is not bound to the trusted GitHub App installation

Summary

This report describes a potential incomplete remediation of the status-check spoofing vulnerability addressed by #3746.

PR #3746 added origin validation to unified-status-check after identifying that status checks associated with fork repositories could influence the unified status calculation.

The remediation establishes a strong repository-origin check for CheckRun objects.

For legacy StatusContext objects, however, the trust decision is different. The implementation relies on the status creator login being in a hardcoded trusted list, together with a targetUrl check intended to reject statuses pointing to a fork.

For PullApprove, this means a status can be accepted based on the global bot identity pullapprove[bot] without establishing that the status originated from the specific trusted PullApprove GitHub App installation authorized for the upstream repository.

The security distinction is:

Recognizing the integration identity is not equivalent to proving the authority of the installation that produced the status.

I reported this to Google under reference 559906863. Google has authorized publication of the technical details and reproduction evidence in the public GitHub issue and indicated that classification depends on OSS maintainer assessment.

Relationship to #3746

PR #3746 is titled:

fix(github-actions): prevent status check bypass via fork spoofing

Its description states that the previous unified-status-check behavior constituted a security vulnerability.

The remediation added:

• headRepository
• checkSuite.repository for CheckRun
• creator.login and targetUrl for StatusContext

The resulting security model is materially different between the two GitHub result types.

CheckRun

The remediation validates repository provenance through:

checkSuite.repository

This binds the check to repository origin.

StatusContext

The legacy status path instead determines trust using the creator identity and, for fork PRs, characteristics of targetUrl.

Trusted status creators include identities such as:

• github-actions
• angular-robot
• ngbot
• pullapprove

and corresponding [bot] variants.

For PullApprove, this establishes that the status appears to have been created by the PullApprove integration identity.

It does not establish which PullApprove installation had authority to produce the status.

That distinction is the subject of this report.

Code reviewed

The analysis was performed against:

angular/dev-infra@183403ae13b785698eaf13c819dda55b9fed430b

Relevant implementation:

github-actions/unified-status-check/lib/pull-request.ts

The downstream consumer examined was Angular's Merge Ready workflow in:

angular/angular/.github/workflows/merge-ready-status.yml

The purpose of this report is not to claim that every status accepted by this path is attacker-controlled.

The narrower question is whether the trust predicate itself proves the authority that #3746 intended to establish.

Trust invariant

For a status that contributes to a security-sensitive aggregate decision, the required invariant should be equivalent to:

A successful status is accepted only when its provenance is bound to an integration installation authorized to produce that status for the protected repository.

The current legacy StatusContext predicate establishes something weaker:

A successful status is accepted when its creator login matches a trusted integration identity and the applicable target URL heuristic does not identify it as originating from the fork.

These are not equivalent predicates.

A GitHub App identity is global.

A GitHub App installation represents scoped authority.

Trusting the former does not, by itself, establish the latter.

Deterministic reproduction

I constructed a local deterministic model of the relevant trust predicate.

No Angular production state was modified.

The model contains two distinct GitHub App installations:

Trusted upstream installation:
installation_id = 111111
creator.login   = pullapprove[bot]

Separate installation:
installation_id = 222222
creator.login   = pullapprove[bot]

Both installations legitimately share the same global GitHub App bot identity:

pullapprove[bot]

The test status from the second installation uses:

context = pullapprove
state   = success
creator = pullapprove[bot]

and a provider-hosted target URL that does not identify the attacker's fork repository.

Existing trust predicate

Under the modeled StatusContext predicate derived from the implementation, the second-installation fixture is accepted.

Result:

other installation status: ACCEPT

Installation-bound predicate

The same fixture is then evaluated with installation identity included as an authority requirement.

Expected trusted installation:

111111

Observed installation:

222222

Result:

other installation status: REJECT

The deterministic harness exited successfully and did not interact with or modify Angular production infrastructure.

The reproduction demonstrates the predicate gap:

same bot identity != same installation authority

Why creator.login is insufficient

The value:

pullapprove[bot]

answers:

Which GitHub App identity created this status?

It does not necessarily answer:

Was this produced under the installation authorized to act for the protected Angular repository?

Those are different authorization questions.

If multiple installations of the same GitHub App can produce legacy commit statuses carrying the same creator identity, then a creator allowlist authenticates the application identity but does not independently establish repository-scoped authority.

Why the targetUrl check does not close the same boundary

The targetUrl mitigation introduced in #3746 addresses the previously demonstrated fork-origin condition by identifying statuses whose target URL points toward the fork repository.

That is useful provenance information.

It is not equivalent to installation authentication.

A provider-hosted status URL can identify the service that produced a result without cryptographically or structurally establishing that the particular service installation was authorized for the upstream repository.

The questions are different:

Does this URL appear to originate from the fork?

versus:

Was the principal producing this status authorized by the upstream repository?

The first does not necessarily prove the second.

Expected behavior

A security-sensitive status consumed by unified-status-check should have provenance sufficient to establish its authority for the protected repository.

Where GitHub exposes repository or installation provenance, the decision should bind to that provenance rather than relying solely on a globally shared bot login.

Conceptually:

trusted app identity
AND
trusted installation/repository authority
AND
expected status context
AND
expected commit

rather than:

trusted creator login
AND
target URL does not look like the fork

Actual behavior demonstrated by the model

For the evaluated legacy StatusContext path, the trust decision does not identify the installation that conferred authority.

Consequently, two modeled statuses can differ in installation authority while presenting the same attributes used by the existing trust predicate.

The existing predicate accepts the second-installation fixture.

An installation-bound predicate rejects it.

Security consequence

The demonstrated issue is an authorization/provenance gap in the legacy status trust predicate.

If a status produced through another installation of a trusted integration is reachable on a commit evaluated by the Angular workflow, the current predicate does not itself distinguish that status from one produced under the intended installation based on installation authority.

Because the status participates in unified-status-check, that creates a potential path for an improperly authorized status to influence Angular's aggregate Merge Ready decision.

This report does not claim that I demonstrated:

• an unauthorized merge into Angular
• arbitrary code execution
• access to Angular secrets
• production compromise
• release compromise
• cross-installation production reachability

Those consequences have not been established by this reproduction.

The demonstrated result is narrower and precedes those consequences: the authorization predicate accepts modeled provenance that differs in the authority dimension the predicate does not inspect.

Why this appears to be incomplete remediation rather than an unrelated issue

#3746 explicitly addressed trust in status-check provenance.

Its remediation correctly introduced repository-origin validation for CheckRun.

For legacy StatusContext, the remediation instead uses an identity allowlist and URL heuristic.

The original vulnerability class was therefore addressed at one provenance layer, but the legacy status path appears to retain a weaker authority model.

The residual question is not whether the creator claims to be PullApprove.

The residual question is:

Which PullApprove authority produced the status, and was that authority authorized for the protected repository?

Requested maintainer assessment

I would appreciate maintainer guidance on the following:

1. Is a legacy StatusContext created by pullapprove[bot] guaranteed by GitHub or PullApprove to have originated only from the PullApprove installation authorized for the upstream Angular repository?

2. If so, what platform or application invariant provides that guarantee?

3. Does the GraphQL representation consumed by unified-status-check expose sufficient repository, application, or installation provenance to bind the status to the intended authority?

4. If installation provenance is unavailable for legacy commit statuses, should PullApprove's legacy StatusContext be considered sufficiently authoritative for a security-sensitive Merge Ready aggregation?

5. Would migration to an installation-bound CheckRun or another repository-bound signal be the preferred remediation?

Suggested remediation direction

I am intentionally not prescribing an implementation before maintainers confirm the platform guarantees.

The security property should be:

status identity + repository-scoped authority

not merely:

status identity

Possible remediation classes include:

• consume a result type carrying repository-bound provenance
• validate GitHub App installation/repository authority where that information is available
• stop treating legacy statuses lacking sufficient provenance as authoritative for the aggregate decision
• migrate the PullApprove contribution to a provenance model equivalent to the CheckRun validation introduced in fix(github-actions): prevent status check bypass via fork spoofing #3746

The appropriate implementation depends on GitHub and PullApprove's actual guarantees.

Verification criterion

A regression test should contain two status producers sharing the same trusted application identity but possessing different repository/install authority.

The test should establish:

authorized installation + expected status -> ACCEPT
different installation + same bot identity + same context -> REJECT

Changing only the provider-hosted URL should not substitute for proving repository-scoped authority.

Disclosure

This issue corresponds to Google report:

559906863: Incomplete remediation of Angular fork-status bypass: PullApprove authority is not bound to the trusted GitHub App installation

Google has explicitly permitted the technical details and reproduction evidence to be shared in the public GitHub issue and has indicated that status and classification will depend on assessment and feedback from the OSS maintainers.

I am filing this publicly pursuant to that direction and would appreciate maintainer technical assessment of the authority invariant described above.

[alan-agius4]

Hello Maurice,

While we acknowledge your observation regarding the lack of repository provenance in GitHub's legacy Commit Status API (StatusContext), this does not constitute an exploitable security vulnerability: the only workflow referencing unified-status-check (merge-ready-status.yml in angular/angular) is manually disabled in GitHub Actions and has never executed in production, and the action functions solely as an informational rollup check rather than an authorization mechanism for merges, which are strictly gated by repository branch protections, required reviews, and Caretaker tooling (ng-dev pr merge).

Because there is no production reachability or security impact, we are closing this advisory as invalid.

[blocksifrdev]

Thank you for the response. I understand your position, but the conclusion that this advisory is “invalid” is not yet supported by the facts stated in your message. The underlying technical issue remains: GitHub legacy StatusContext objects do not provide the same repository provenance guarantees available with CheckRun objects. Your own unified-status-check implementation treats status origin as security-relevant by validating upstream repository provenance for CheckRun objects and separately attempting to establish trust for StatusContext objects through creator identity and target URL checks. That is not merely an informational distinction. It is an explicit trust decision. Your response therefore appears to combine two separate questions: 1. Whether the provenance weakness exists. 2. Whether that weakness is reachable through a production authorization path in angular/angular. The first issue is established by the implementation itself. The second requires evidence. Specifically, if your position is that there is no production security impact, please provide or confirm the factual basis for the following: * That merge-ready-status.yml is presently disabled at the GitHub Actions configuration level. * The date on which it was disabled. * Whether the workflow ever executed before being disabled. * Whether Merge Ready Tracking has ever been configured as a required status check through branch protection or repository rulesets. * Whether the result of unified-status-check is consumed, directly or indirectly, by ng-dev pr merge, Caretaker automation, labels, bots, merge queues, or any other mechanism involved in determining merge eligibility. * Whether any StatusContext processed by this system could affect the combined status information relied upon by those mechanisms. The fact that other controls exist, including required reviews, branch protections, and Caretaker tooling, does not by itself establish that this path has no security consequence. The relevant question is whether the affected status information can influence any decision within that control chain. If the workflow has truly never executed in production and its output has never participated in merge authorization, then the appropriate conclusion may be that the underlying weakness is real but not production-reachable in angular/angular. That is materially different from stating that the advisory is invalid. At this point, I would characterize the available evidence as follows: Primitive weakness: CONFIRMED Security relevance of provenance: CONFIRMED Production reachability: NOT YET ESTABLISHED Merge authorization consequence: NOT YET ESTABLISHED I am therefore asking that the advisory not be closed as invalid based solely on the assertions in the current response. Please provide the supporting evidence establishing the absence of production reachability, after which the impact classification can be evaluated on the complete record. Regards, Maurice Witten BlockSiFr Security Research Maurice Witten Architect BlockSiFr LLC 📧 ***@***.*** 🌐 blocksifr.com 📞 470.909.0822 ***@***.***?anonymous&ep=signature&ismsaljsauthenabled> Book time to meet with ***@***.***?anonymous&ep=signature&ismsaljsauthenabled>

…

________________________________ From: Alan Agius ***@***.***> Sent: Tuesday, September 22, 2026 10:20 To: angular/dev-infra ***@***.***> Cc: Maurice Witten ***@***.***>; Author ***@***.***> Subject: Re: [angular/dev-infra] Incomplete remediation of fork-status bypass: PullApprove authority is not bound to the trusted GitHub App installation (Issue #3987) Closed #3987<#3987> as not planned. — Reply to this email directly, view it on GitHub<#3987?email_source=notifications&email_token=B2HS6GU7QCJB3YAXT7A32FT5QKDDJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMJWGA3DMMZYG42TNJTSMVQXG33OUZQXK5DIN5ZKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#event-31606638756>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B2HS6GUFSAI5RKFHFMOOYQT5QKDDJAVCNFSNUABFKJSXA33TNF2G64TZHMYTSMZXGYYDQNZSHNEXG43VMU5TKNJRGM3TIMZQGY22C5QC>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[alan-agius4]

To confirm the facts requested:

1. Workflow execution: merge-ready-status.yml was manually disabled in GitHub Actions on December 15, 2022 (state: disabled_manually) and has 0 lifetime runs.
2. Merge authorization: "Merge Ready Tracking" was never configured as a required check in branch protections or rulesets, nor was it ever consumed by ng-dev pr merge, Caretaker tooling, or merge queues.
3. Action removal: Because the action is obsolete and unused, it is being removed entirely from both repositories (see angular/angular#70855 and angular/dev-infra#3989).

Given the complete absence of production reachability and security impact, closing the issue and advisory as invalid reflects that this does not constitute an actionable vulnerability.

[blocksifrdev]

Thank you for the detailed follow-up and for taking the time to provide the historical execution and authorization context. That information was exactly what we needed to close the loop properly. Once the zero-run history, disabled state, and absence of any merge-authorization dependency were established, the consequence path was no longer supportable. I also want to thank you for engaging with the technical substance of the report. That was genuinely useful to us. At BlockSiFr, we are building a broader security and consequence-intelligence system focused on a question that traditional vulnerability analysis often stops short of answering: What can this actually cause? Our research process separates the existence of a weakness from production reachability, authority, execution path, and ultimately consequence. In this case, the provenance asymmetry around GitHub StatusContext was a real technical observation, but your evidence demonstrated that it did not connect to an operative authorization path in Angular. That distinction is important to what we are building. We are developing systems that map findings through a progression of evidence, reachability, authority, execution, and consequence so that customers can distinguish between interesting technical conditions and vulnerabilities that can actually produce material outcomes. Your response helped us improve that methodology by reinforcing an important rule: a technically valid primitive should not be elevated into a vulnerability claim unless the consequential path can be proven. That makes our research stronger, our classifications more disciplined, and ultimately reduces false positives for the teams receiving our findings. I appreciate the professionalism and the additional evidence. Regards, Maurice Witten BlockSiFr Security Research

…

________________________________ From: Alan Agius ***@***.***> Sent: Tuesday, September 22, 2026 11:17 To: angular/dev-infra ***@***.***> Cc: Maurice Witten ***@***.***>; Author ***@***.***> Subject: Re: [angular/dev-infra] Incomplete remediation of fork-status bypass: PullApprove authority is not bound to the trusted GitHub App installation (Issue #3987) [https://avatars.githubusercontent.com/u/17563226?s=20&v=4]alan-agius4 left a comment (angular/dev-infra#3987)<#3987 (comment)> To confirm the facts requested: 1. Workflow execution: merge-ready-status.yml was manually disabled in GitHub Actions on December 15, 2022 (state: disabled_manually) and has 0 lifetime runs. 2. Merge authorization: "Merge Ready Tracking" was never configured as a required check in branch protections or rulesets, nor was it ever consumed by ng-dev pr merge, Caretaker tooling, or merge queues. 3. Action removal: Because the action is obsolete and unused, it is being removed entirely from both repositories (see angular/angular#70855<angular/angular#70855> and angular/dev-infra#3989<#3989>). Given the complete absence of production reachability and security impact, closing the issue and advisory as invalid reflects that this does not constitute an actionable vulnerability. — Reply to this email directly, view it on GitHub<#3987?email_source=notifications&email_token=B2HS6GV55B7RU2TWVX4PCK35QKJYVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZXHEYDOOBSHE4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5779078298>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B2HS6GR36GJKW2PTKEJV4J35QKJYVAVCNFSNUABFKJSXA33TNF2G64TZHMYTSMZXGYYDQNZSHNEXG43VMU5TKNJRGM3TIMZQGY22C5QC>. You are receiving this because you authored the thread.Message ID: ***@***.***>