Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Updates System
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
2 Mar 2026 at 16:52 UTC
Updated:
18 Mar 2026 at 10:45 UTC
Jump to comment: Most recent
Via @mxr576 in Slack:
Since Friday my builds on Drupal Dependency Quality Gate are failing due to HTTP 403 - I did not know that is a possible HTTP code on that endpoint.
Next RuntimeException: Failed to fetch project information for "3545283". Reason: "Client error: `GET https://updates.drupal.org/release-history/3545283/current` resulted in a `403 Forbidden` response:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initia (truncated...)
". in /home/runner/work/ddqg/ddqg/src/Infrastructure/DrupalOrg/UpdateStatusApi/DrupalUpdateStatusApiUsingGuzzleRepository.php:173
https://github.com/mxr576/ddqg/actions/runs/22558994249/job/65341631459
Also reported to the security team from @arnested:
We monitor for security updates by fetching
https://updates.drupal.org/release-history/drupal/all from GitHub Actions.Since February 28 we have been getting 403 errors when trying to get the URL in GitHub Actions (but not from other locations).
Have GitHub's IP addresses been put on a deny list or something?
Comments
Comment #2
mxr576Comment #3
mxr576I have also managed to reproduce the HTTP 403 on my local. Now I am trying to get the complete HTTP response if that helps with further debugging.
Comment #4
xem8vfdh commentedSame here for all of my modules/packages. I'm getting 503s
Comment #5
eluchel commentedSame here for my modules/core. When I check for updates manually I will either fail to get update data for everything (503 errors), or only for a few of my modules.
Edit: it is fixed for me now
Comment #6
mxr576403 is PerimeterX, just as I thought
https://github.com/mxr576/ddqg/actions/runs/22586865524/job/65434081489#...
Comment #7
drummWe spotted a couple misconfigurations that were causing this issue and should be resolved now.
I attempted to simplify part of the CDN configuration leftover from years ago. This resulted in some updates.drupal.org traffic actually being handled by the general *.drupal.org service. updates.drupal.org does not have PerimeterX set up at all, but if its routing via *.drupal.org’s configuration, that would add it.
We also spotted that another bot protection product had been enabled, that is now off again.
updates.drupal.org has a 99.99% cache hit rate, so the underlying issue was masked until people started pushing code to git.drupalcode.org on Monday. The request to
https://updates.drupal.org/release-history/3545283/currentalso didn’t trigger any concern because numeric project names are sandboxes, that never have release history.Comment #9
mxr576Thanks, CDN related to be working, however, I must say the project behind https://updates.drupal.org/release-history/3545283/current seems like an interesting one, indeed, it has a numerical ID, but from its project page does not look like a sandbox project, and https://www.drupal.org/api-d7/node.json?nid=3545283 also returns
field_project_type: true.Comment #10
arnested commentedThank you.
I can confirm our GitHub Actions are getting access again.
Kind regards
Arne
Comment #11
avpaderno@mxr576 It is a full project, but it does not have releases. There is a branch, for which a tag has been created, but no releases.
Comment #12
mxr576Agreed, my reaction was challenged this previous sentence: