[GSoC 2026] Proposal Draft: Admin API Fuzzer - Prateek

[PRATEEK]

Hello Qubes OS Team,

My name is Prateek. I am an 2 year Engineering student , interested in Ethical Hacking and Cyber Security. I am preparing a proposal for the "Admin API Fuzzer" GSoC 2026 project.

To be completely transparent, I am currently spending my time deep-diving into the qubesd architecture. While my background is in offensive security and automated payload injection (I previously engineered a Python-based Runtime Application Self-Protection simulator), Qubes OS is a new and exciting environment for me.

My current learning strategy is a "bottom-up" approach: I am starting with the basic event routing and outer defenses before moving into the core logic of the API. I would greatly appreciate feedback from the community—especially from Marek as the prospective mentor—on whether this is a solid approach to mastering the architecture.

While reading the code this week, I spotted a few areas—specifically the hardcoded string-checkers in the event routing and the sequential parsing of untrusted_payloads—that look to me like potential targets for case-mutation and parser confusion. Because I am still learning the system, I do not want to jump to conclusions, so I would love your feedback on whether my hacker mindset is pointing me in the right direction. To test my understanding, I am attempting to write a small Pull Request today to harden one of these string-checkers.

Here is my initial proposal draft. I welcome any and all critiques!

GSoC 2026 Proposal Draft: Admin API Fuzzer

# Introduction The Qubes OS Admin API is the critical bridge that allows VMs to execute privileged actions. Because qubesd relies on the qrexec RPC policy to mediate these actions, vulnerabilities in the API—such as improper input sanitization—can lead to severe policy bypasses. My goal is to develop an automated, highly extensible Python Fuzzer specifically targeting the Admin API to systematically expose unhandled exceptions and parser confusion before they reach production.

# Project Goals During the 12-week GSoC period, I will deliver:

1. Target Integration: A native Python test harness to interact directly with the admin.* endpoints.

2. Automated Payload Generation: A mutation engine capable of generating malformed strings, corrupted device serialization formats, and boundary-breaking integers.

3. Crash Monitoring: A continuous loop observing the qubesd daemon to log unhandled exceptions and state crashes.

4. Documentation: Clear guidelines on how developers can run the fuzzer locally against new PRs.

# Implementation & Technical Architecture

Based on previous mailing list discussions, I understand that utilizing a standard containerized pipeline (like OSS-Fuzz) is impractical for qubesd due to its reliance on a native environment. Therefore, I will engineer a custom Python fuzzing harness to run safely within an isolated Qubes OS test bench.

The fuzzer will utilize the following targeted mutation strategies to attack specific architectural layers:

• Testing Outer Defenses (String Checks): Think of mechanisms like QubesMgmtEventsDispatcher as the security cameras outside the main vault (QubesAdminAPI). Qubes OS utilizes strict, hardcoded string matchers here (e.g., event.startswith("admin-permission:")). The fuzzer will aggressively utilize case mutation (e.g., Admin-Permission:) and special-character injection (e.g., null bytes, unexpected newlines) to stress-test these initial filters. Just as blinding a security camera is a critical flaw even if the inner vault remains locked, bypassing this first layer seems like a major potential vulnerability to target, even if the secondary apply_filters ACL catches it later.

• Parser Confusion (Layered Attacks): Standard sequential filters can create blind spots when processing complex untrusted_payload data. The fuzzer will generate layered attacks—combining serialization mangling with escape-character injection—to see if standard .split() and .decode() methods inadvertently assemble malicious commands when parsing complex arguments.

• Boundary Exceedance: Continuously injecting extreme integers into size-validation endpoints (like admin.vm.volume.Resize) while monitoring the libvirtd state to catch memory leaks or Denial of Service conditions.

Thank you for your time and guidance. I look forward to learning from your feedback.

Best regards

Prateek

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> *# Introduction* The Qubes OS Admin API is the critical bridge that allows

> VMs to execute privileged actions. Because qubesd relies on the qrexec RPC
> policy to mediate these actions, vulnerabilities in the API—such as
> improper input sanitization—can lead to severe policy bypasses. My goal is
> to develop an automated, highly extensible Python Fuzzer specifically
> targeting the Admin API to systematically expose unhandled exceptions and
> parser confusion before they reach production.
>

> *# Project Goals* During the 12-week GSoC period, I will deliver:
>
> 1.
>
> *Target Integration:* A native Python test harness to interact directly
> with the admin.* endpoints.
> 2.
>
> *Automated Payload Generation:* A mutation engine capable of generating

> malformed strings, corrupted device serialization formats, and
> boundary-breaking integers.

> 3.
>
> *Crash Monitoring:* A continuous loop observing the qubesd daemon to log

> unhandled exceptions and state crashes.

It might be interesting to also consider information leak here. Things
like responding with improperly formatted output for example leaking
info about more objects or properties than requested.

But, that's just an optional idea to consider, don't stretch the scope
too much. Plan what you can realistically deliver.

> 4.
>
> *Documentation:* Clear guidelines on how developers can run the fuzzer
> locally against new PRs.
>
> *# Implementation & Technical Architecture*

>
> Based on previous mailing list discussions, I understand that utilizing a
> standard containerized pipeline (like OSS-Fuzz) is impractical for qubesd
> due to its reliance on a native environment. Therefore, I will engineer a
> custom Python fuzzing harness to run safely within an isolated Qubes OS
> test bench.
>
> The fuzzer will utilize the following targeted mutation strategies to
> attack specific architectural layers:
>

> -
>
> *Testing Outer Defenses (String Checks):* Think of mechanisms like

> QubesMgmtEventsDispatcher as the security cameras outside the main vault
> (QubesAdminAPI). Qubes OS utilizes strict, hardcoded string matchers here
> (e.g., event.startswith("admin-permission:")). The fuzzer will aggressively
> utilize case mutation (e.g., Admin-Permission:) and special-character
> injection (e.g., null bytes, unexpected newlines) to stress-test these
> initial filters. Just as blinding a security camera is a critical flaw even
> if the inner vault remains locked, bypassing this first layer seems like a
> major potential vulnerability to target, even if the secondary
> apply_filters ACL catches it later.

Note that events are generated within qubesd, not coming from outside,
so attacker (nor fuzzer) cannot influence what events are sent there.
But, that's also interesting point - if the fuzzer finds a way to inject
an event, that could be a problem.

> -
>
> *Parser Confusion (Layered Attacks):* Standard sequential filters can

> create blind spots when processing complex untrusted_payload data. The
> fuzzer will generate layered attacks—combining serialization mangling with
> escape-character injection—to see if standard .split() and .decode()
> methods inadvertently assemble malicious commands when parsing complex
> arguments.

> -
>
> *Boundary Exceedance:* Continuously injecting extreme integers into

> size-validation endpoints (like admin.vm.volume.Resize) while monitoring
> the libvirtd state to catch memory leaks or Denial of Service conditions.

Sounds good :)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmm3Zv4ACgkQ24/THMrX
1yzEfggAj/aVQ2xJXzyLz3ONGqfmoRmE/D4THeJ0Zk40tZzLQCJrJPV1TOQwpVlk
hKZRNyJ9xqPY20m9UIx6ynJRlSbeuKKJUB5fy1+SphTjaKkkQh3lcdkxz2irn0Rb
ADsjN4UUZNvEHo1fNUu4KcVu+0cyRtiCF46BAfQE/0z/ldCf3ymUma6LHUArvqmc
ohz/S3SPxDD3h3oJvtFqd0xq8MTq9d4xuUYLZVR1ORSuR+RzM7BEqaSbKQU55cpa
2ftL6+pfUcevIVfluuuFjOITUSJP8QQZg9/9ekrqwI6Ylo2GtHiTz5VejlRxxqM9
23aajNfdLX6kd0yBHiSJ71E+7LkwYw==
=bReO
-----END PGP SIGNATURE-----