ControlPlane AI Security Team Reports Cross-Account Access in the General Aviation Reporting Service

A ControlPlane security research note. Reported and resolved through the Home Office’s vulnerability disclosure programme. Published with coordinated timing after remediation.

Summary

ControlPlane's AI security research team found that the Home Office's General Aviation Report service (opens in a new tab) could reject an attempt to select someone else's report yet leave it available for subsequent reads and changes.

Testing with two controlled accounts reported passenger data access, passenger removal, and report cancellation. Later source review found checks added before report selection and on the affected operations.

Once reported, the Home Office confirmed the issue and remediated it. Severity was assessed as High, CVSS 8.8 (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), classified under CWE-862 (Missing Authorisation / Broken Object Level Authorisation).

Background

The General Aviation Report service (opens in a new tab) records flight and passenger details for border reporting, including travel-document information. Users sign in through GOV.UK One Login (opens in a new tab), the government's shared sign-in service.

The application stores the currently selected report in a session (opens in a new tab) saved state that follows the user between pages. Later operations use that selection to decide which report to read or change.

The finding

The selection code saved the supplied report identifier before checking ownership. If the check failed, it directed the browser to the home page but left the selection changed. A small local test program, using application code with a simulated data service, showed that another page could then read the selected report's passenger list.

The production test depended on stopping before the home-page redirect. Following it would have cleared the selection. With that extra request withheld, the team reported that they had read the second account's passenger details, removed a passenger, and cancelled its report. The removal and cancellation were checked from the second account.

Root cause

The application changed its saved state before deciding whether the caller was allowed to select the report. Rejecting the page did not undo that change.

The passenger-list and cancellation operations then trusted the saved selection without checking ownership themselves. Authorisation for each request (opens in a new tab) means checking that the current user can perform that operation on that report, regardless of where its identifier is stored.

Potential impact

The controlled test demonstrated access to passenger and travel-document information, as well as changes to another test account's report. Against an unrelated account, the same behaviour could expose travel details or disrupt a submission.

Testing supplied a known report identifier from the second account. It didn’t establish how an attacker would discover arbitrary users' report identifiers.

Coordinated disclosure and remediation

Source review on August 4, 2026 found that ownership was checked before the report selection was saved. Failure also cleared the selection. The shared check covered the affected report-view, passenger-list and cancellation operations.

No live remediation retest or deployment date is recorded, and the programme had not confirmed production remediation.

Disclosure timeline: times below are UTC; the live-test entry dates the report of its results.

Date and time

Event

Jun 18, 2026, 13:54:56 UTC: Finding reported with code review and local-test evidence.

Jul 21, 2026, 11:23:42 UTC: Controlled production results reported.

Aug 4, 2026, 13:19:28 UTC: Source review recorded ownership checks before selection and on affected operations.

Oct 14, 2026, 13:24:45 UTC: Programme resolved the report.

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. The production test used two accounts controlled by the research team. No unrelated person's data was accessed. The earlier local test used a simulated data service rather than the production data service.

The broader lesson

Three points apply well beyond this service:

• Authorise before changing state. Nothing should be written to a session, cache or database until the access check has passed, or a refused request can still leave something behind for the next one to use.
• Do not let one step vouch for the next. Every request that reads or changes a record should check its own access, rather than trusting a reference stored earlier in the journey.
• Test the failure path, not only the response. After a request is refused, check what the same user can do next, including going straight to a later page instead of following the redirect.

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 and non-human identities without sacrificing usability. If you are building cloud services that must remain both open and safe, we would be happy to talk (opens in a new tab).