Incident Library
Applied filters Root causeBreaking change in an upgradeComponentWeb application firewall rulesOrganisationUK Ministry of JusticeClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    At 08:56 on 30 March 2026, about an hour and three quarters after the rollout of a new ingress-nginx to production began, the MoJ Cloud Platform team noticed messages in the #hmpps-auth-audit-registers Slack channel about ModSecurity unexpectedly blocking requests. Users in HMPPS also raised incidents with the MoJ service desk.

    Trigger

    The Cloud Platform team began deploying ingress-nginx 1.14.3, on images maintained by Chainguard, to the three production ingresses at 07:11 on 30 March 2026.

    Root cause
    Component
    Contributing factor
    Detection

    At 08:56 the Cloud Platform team saw messages in the #hmpps-auth-audit-registers Slack channel showing ModSecurity blocking requests unexpectedly; HMPPS users also raised incidents with the MoJ service desk.

    Remediation
    • rolled the ingress-nginx deployment back to the previous version, from 09:14 to 09:43
    • HMPPS applied ModSecurity rule exclusions for the rules blocking traffic to HMPPS Auth
    • added a temporary global exclusion for the CRS rule triggered by the PostHog cookie
    • redeployed ingress-nginx 1.14.3 with both exclusions in place, completed at 14:00
    Action items
    • Rescope the PostHog cookie so it is no longer sent with requests to all *.justice.gov.uk services
    • Remove the temporary global exclusion once the PostHog cookie has expired from enough users' browsers
    • Remind service teams to run dev and test workloads through the non-production ingress controllers so future ModSecurity and CRS updates are tested
    • Run production and non-production workloads in separate clusters in Cloud Platform 3.0, so non-production workloads must use the non-production ingress
    Lessons

    An ingress controller upgrade that bundles a web application firewall also changes which requests are allowed, not only how they are routed. A beta or non-production ingress only catches false positives for traffic that actually passes through it, and teams that keep their test workloads on the production ingress miss them. A fix on the client side, such as rescoping a cookie, takes effect only when old cookies have expired in users' browsers, so the rule change has to wait for it or ship with an exclusion.

Check your cluster for this

This case involves Ingress controller and Web application firewall rules. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1