- A GitHub advisory says one link opened by a signed-in TinaCMS editor lets an outside attacker read and change content as that editor.
- The admin trusted a preview address taken from the URL, so the attacker's site passed the origin check meant to block it.
- Teams running the TinaCMS admin should confirm their version against the advisory and the maintainers' release notes, and review what editor accounts can reach.
A check is only as strong as what it compares against
Many security checks fail without being missing. They compare a visitor against a value the visitor supplied. Picture a doorman who checks each guest's name against a list, and the guest hands him the list. Everyone gets in.
That is the pattern in advisory GHSA-x34j-47hf-4xg7, published on October 9 in the GitHub Advisory Database. It describes a flaw in the TinaCMS admin, the editing screen used to manage a site's content. The advisory carries no CVE ID in the text we reviewed.
How the attack works
The TinaCMS admin shows a live preview of a page inside an iframe, a frame that displays another web page. The frame's address comes from the part of the admin URL after /~/. The admin does not check that this address stays on the same site.
An attacker can craft a link whose fragment, the part after the # sign, contains a doubled slash: #/~//attacker.example/p. The router returns the address with its own leading slash. The result is //attacker.example/p, which a browser reads as a link to another site.
Two browser safeguards could have limited the damage, and neither is in place. The advisory notes the frame is missing a sandbox attribute, which restricts what embedded pages may do. It also says the admin bundle sets no content security policy, a rule set that limits what a page may load or run.
The deeper problem is the trust check. The admin and the preview talk through postMessage, the browser's way for two frames to pass messages. The admin accepts messages only from an expected origin. But it works out that origin from the same unchecked address.
So the attacker's site becomes the expected origin. Both guards pass: the message comes from the expected origin, and from the frame the admin itself loaded.
What the attacker gets
The attacker's frame can send any GraphQL operation. GraphQL is the query language the content API speaks. The admin carries out each request using the signed-in editor's token, then sends the result back to the attacker's own site. According to the advisory, the function that prepares queries does not filter by operation type, so changes pass through untouched.
The advisory says the attacker can read anything the editor can read. On self-hosted setups, that includes the authentication collection holding PBKDF2 password hashes. The attacker can also run any change the editor can, including updateDocument, createDocument and deleteDocument.
The link's payload lives after the # sign, and browsers do not send that part to the server. A defender reading web server records would therefore find no trace of it.
The advisory also says no setting switches the route off. Every tinacms build output includes it, as does the tinacms dev server.
An earlier fix stopped one step short
The advisory notes that tinacms 3.9.3 and @tinacms/app 2.5.6 added a check on the sender's origin. That fix never validated the address the check compares against. The guard was real, but its reference value was not trustworthy.
This is the lesson for any team. When a hardening release ships, ask what the new check compares against, not only whether a check exists.
What the report does and does not establish
The reporter tested only tinacms 3.12.1 and @tinacms/app 2.5.12. The affected ranges are written as "<=" because the vulnerable lines match across every commit the reporter could see. The true lower bound is undetermined, and the reporter asked the maintainers to narrow it.
The proof of concept ran locally with two loopback origins. The backend call was stubbed, so no live TinaCloud or self-hosted backend was contacted. The report shows the unsafe steps happen in the admin code. It does not show an attack on a real site.
The advisory links to releases tinacms 3.14.0 and @tinacms/app 2.5.14. Its text does not say outright that these fix the flaw. Confirm that with the maintainers' release notes.
Questions to put to your team
First, do we run the TinaCMS admin anywhere, including development servers? Which versions? Compare them with the advisory, the linked releases and the maintainers' release notes. The advisory gives no clean list of affected versions.
Second, what can an editor account reach? If one token can read credentials and delete content, one link carries that whole reach. Narrower roles shrink the damage.
Third, on self-hosted setups, are password hashes stored in the same content API editors can query? The advisory says they can be exposed there.
Fourth, can we add a content security policy or a sandbox around the preview frame while we update? The reporter's suggested fix is to reject addresses that begin with a slash or backslash. The origin helper should also refuse anything but the page's own origin.
Finally, tell editors to treat admin links from outside the team with the same care as a request to enter their password.
A trust check that compares against attacker-supplied input is not a check at all. It only looks like one.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
