The Department for Education 'Get Help Buying for Schools' Vulnerability Disclosure

ControlPlane's AI security research team identified an access-control gap in the Department for Education's "Get help buying for schools" service, which supports schools through public procurement and supplier frameworks. The service's multi-step request form did not tie a request to the session that created it, and anyone who held a request's identifier could change the request's details (including its contact email) and submit it, without signing in to the service.

Once reported, the Department for Education confirmed and remediated the issue. Severity was assessed as Medium, CVSS 6.5 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N), classified under CWE-285/CWE-862 (Improper/Missing Authorisation) and CWE-639 (IDOR).

Background

The Department for Education's multi-step wizard guides schools through a procurement support request. As there is no centralised IdP to authenticate school staff, there is no way to verify the user's identity. So the application is left to determine _which_ request a given visitor is allowed to act on.

The finding

Every step of the wizard resolved the request directly from an identifier in the URL. The controllers that those steps inherited from skipped authentication and did not check the identifier against anything in the visitor's session.

In effect, the request identifier was both the name of the request and the permission to change it.

A party that possessed a valid request identifier could therefore modify fields on that request, including replacing the contact email address with one they controlled, and force the request to be submitted, all without authenticating. Meaning once a genuine support case had been submitted to the department's system, subsequent correspondence for that request could be unknowingly directed to the modified contact details.

ControlPlane validated this non-destructively against a test request for a placeholder school, using a placeholder contact address.

Root cause

The security design flaw is the "identifier as secret" assumption. The request identifier was a long, randomly generated value: high entropy, and therefore easy to mistake for a secret. This is the most prevalent issue in the OWASP Top 10, A01:2025 Broken Access Control (opens in a new tab).

Identifiers of this kind are routinely exposed in ordinary use, including in notification and confirmation emails, links that get forwarded, browser history and shared devices, and referrer headers.

Potential impact

Once a request has been submitted, an official support case is raised within the system, and all communications are routed to the details provided. By exploiting the identified vulnerability, an unauthorised user with the request identifier could alter case details, including the contact email address, redirecting all subsequent correspondence to an account they control. Ultimately, leaving the legitimate school and the Department for Education unaware of the attacker's presence.

Coordinated disclosure and remediation

The Department for Education scoped the wizard's record lookups, uploads, and removal actions to the active session, so a mismatched identifier returns "not found" rather than granting access. This removed the authentication bypass on write actions.

Disclosure timeline (dates only):

• 2026-06-26: Report submitted through the DfE VDP
• 2026-07-10: Resolved: record lookups scoped to the active session across the wizard

Responsible testing and data handling

Testing followed the GC3 Vulnerability Disclosure Policy (opens in a new tab), which anyone who finds a vulnerability in a public sector service can use. Within that policy, ControlPlane took a minimum-necessary approach: verification was non-destructive, used a researcher-created test request with a placeholder school and contact address, and was limited to what was required to demonstrate the issue.

The broader lesson

Two principles prevent this class of flaw:

1. An identifier is not an authenticator. High entropy is not secrecy. Bind each record to the session or account entitled to it, and check that binding on every request, including "guest" flows that deliberately avoid sign-in.
2. Be deliberate about relaxing security controls for usability. Skipping authentication for a journey is fine; bypassing ownership validation should be avoided. When a flow opts out of one control, it needs to opt into an equivalent one.

About this work

ControlPlane is an AI-native cybersecurity consultancy specialising in cloud native security, secure software supply chains, and the assurance regimes that regulated organisations depend on. We help teams design and secure platforms without sacrificing usability. If you are building services that must be both open and safe, please reach out (opens in a new tab).