Request for Post-Incident Transparency Regarding Azure/functions-action Outage

[tremblaysimon]

Summary

On June 5, 2026, the Azure/functions-action repository became unavailable, causing deployment failures for GitHub Actions workflows relying on Azure/functions-action@v1.

Public discussions and security reports have linked the broader repository disablements affecting Azure-related repositories to the recent Miasma supply-chain incident. At the same time, public communications have described the situation as an "internal management issue" under investigation.

References:

• The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds
• GitHub action Azure/functions-action down
  
• Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents

Questions

Would the Azure Functions team be willing to provide a post-incident summary addressing the following points?

1. Was Azure/functions-action directly affected by the security incident, or was it disabled as a precautionary measure?
2. What was the root cause of the repository unavailability?
3. Were any published action tags, releases, or deployment artifacts impacted?
4. Are there recommended mitigations for users who relied on Azure/functions-action@v1 ?
5. Will there be any changes to versioning guidance (for example, stronger recommendations around immutable commit SHAs instead of mutable tags)?
6. Is a public incident report or postmortem planned?

Many organizations depend on Azure/functions-action for production deployments. Understanding the cause, scope, and remediation steps would help users assess risk, improve their supply-chain security posture, and prepare for similar situations in the future.

Thank you for any information the team can share once the investigation is complete.

[codylund]

Piling on -- were there any public communications about the status of the outage and expected restoration timeline? If so, where?

The repos were deactivated without warning and I could not find any information about when they were expected to come back online. Was it going to be minutes, hours or days?

[rushilShetty]

I agree with @codylund here, we're seeing time and time again such things but the Github status always shows green and says everything is operational. If this was indeed a Miasma worm, which it very likely looks like, then Github has a legal obligation towards its enterprise customers to be transparent about this.

[mrajweir]

Yeah, with the repo(s) being back online, you don't actually know if the root cause has been resolved without guidance from the maintainer. We need to know what happened, how it was resolved, and any advice for folks who rely on the repo.

[swallace-bg]

Adding our voice as another organization that depends on Azure/functions-action in production deployment pipelines.

We appreciate that the repository has been restored, but restoration alone doesn't tell consumers whether what's now being served is safe to consume. Until there's an official statement, every team pulling this action has to choose between blocking their deploys or trusting artifacts whose integrity hasn't been confirmed. A clear word from Microsoft would resolve that for a lot of people at once.

Could the maintainers / Microsoft please confirm the following, ideally in a published post-incident report:

1. Release integrity. Are the tags and release artifacts now served by the restored repository confirmed to be byte-for-byte identical to their pre-incident state? If verification was done, what method was used (hash comparison against a known-good source, rebuild-from-source, etc.)?
2. Activity during the incident window. Were any commits, tags, releases, or artifacts created or modified during the period the repo was disabled/compromised? If so, which specific versions are affected, and which are confirmed clean?
3. Independent verifiability. Are published checksums, signatures, or build provenance/attestations (e.g. SLSA) available so consumers can verify the artifacts they pull rather than relying on trust alone? If not currently, are there plans to add them?
4. A per-version "safe to use" statement. A simple affected / not-affected list by version (and major tag, e.g. @v1) is what most of us actually need to make a go/no-go call.
5. Pinning guidance. Given mutable tags were in scope here, what is the recommended pinning strategy going forward — pin to a verified commit SHA, and if so which SHAs are confirmed good?
6. RCA commitment and timeline. Public communications so far have ranged from references to a supply-chain incident to characterizing it as an "internal management issue under investigation." That inconsistency is itself a problem for downstream risk assessment. Can Microsoft commit to publishing a full root-cause analysis, and give an approximate timeline?

We're not trying to assign blame — we just need enough verified detail to make an informed decision about resuming use. Thank you to everyone involved in the response.

[rushilShetty]

@im-samz can you please comment on this? Thanks

[ckabalan]

We too were affected by this as the repository was blocked in the few hours after our validation release and before we released to production, causing us to miss our go-live window.

One issue is that we could not assess whether a workaround was easily possible or not because the source code was unavailable, so we didn't know how to actually deploy this by hand if we wanted to. Most of the Microsoft documentation points to using this action for deployments, or the VSCode Extension.

I'm wondering if there is way to eliminate the risk by disabling the use of the action, but still allow the source code to be available? For example, setting the "Not Accessible" option in Settings > Actions > General > Access.

[miguellira]

Although it won't address availability, with all of these supply chain attacks it's always best to remind developers to follow best security practices and pin actions to a full-length commit SHA.

Avoid

        - name: 'Run the Azure Functions action'
          uses: Azure/functions-action@v1
          id: deploy-to-function-app
          with:
            app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
            package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}' 

Prefer

        - name: 'Run the Azure Functions action'
          uses: Azure/functions-action@bc63708cc6539760eea18d8a7de4ce8ef5fdf593 # v1.5.6
          id: deploy-to-function-app
          with:
            app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
            package: '${{ env.AZURE_FUNCTIONAPP_PROJECT_PATH }}'

[FrankLouwRP]

Adding our voice. Our organization also relies on Azure/functions-action and saw unexpected outages with zero communication before, during or after the incident. We would appreciate some communication regarding the event and information on how this can be better handled in the future.