I initially reported this to the Google OSS VRP (https://g.co/vulnz).
They acknowledged it as a valid product vulnerability. However, because Magika is classified as an OT2 project, they require a patch to be committed and merged before they can process the report.
They encouraged me to open a public issue to collaborate with the maintainers on a fix, so I am doing that here.
Magika extracts features only from the beginning and end of a file (beg_size=1024, end_size=1024). For files smaller than 1024 bytes, both feature windows contain the exact same content.
Knowing that the goal was simply to keep the score below 0.5, I used Claude to help craft a PoC.
In the PoC below, the file is 958 bytes long: roughly 928 bytes of HTML/JS followed by a 30-byte <?php ... ?> block. Because the HTML/JS content dominates both feature vectors, the PHP signal is relatively weak.
As a result, the model predicts dl=php, but with a score of about 0.489. Due to the low-confidence fallback in python/src/magika/magika.py, the final result becomes output=txt. In other words, Magika returns txt for a file that it internally considers likely to be PHP.
This is also highly position-sensitive. If the PHP block is moved slightly, the score fluctuates across the threshold (for example, 0.506, 0.489, and 0.646). This appears consistent with the current feature extraction design and with where the PHP bytes land inside the two feature windows.
The attached PoC reproduces this behavior and shows that the PHP interpreter still successfully executes the sample.
Because this is my first time handling a security issue through a public issue tracker, I was not sure whether including the full PoC here would be appropriate, so I have not attached it for now.
I initially reported this to the Google OSS VRP (https://g.co/vulnz).
They acknowledged it as a valid product vulnerability. However, because Magika is classified as an OT2 project, they require a patch to be committed and merged before they can process the report.
They encouraged me to open a public issue to collaborate with the maintainers on a fix, so I am doing that here.
Magika extracts features only from the beginning and end of a file (
beg_size=1024,end_size=1024). For files smaller than 1024 bytes, both feature windows contain the exact same content.Knowing that the goal was simply to keep the score below 0.5, I used Claude to help craft a PoC.
In the PoC below, the file is 958 bytes long: roughly 928 bytes of HTML/JS followed by a 30-byte
<?php ... ?>block. Because the HTML/JS content dominates both feature vectors, the PHP signal is relatively weak.As a result, the model predicts
dl=php, but with a score of about 0.489. Due to the low-confidence fallback inpython/src/magika/magika.py, the final result becomesoutput=txt. In other words, Magika returnstxtfor a file that it internally considers likely to be PHP.This is also highly position-sensitive. If the PHP block is moved slightly, the score fluctuates across the threshold (for example, 0.506, 0.489, and 0.646). This appears consistent with the current feature extraction design and with where the PHP bytes land inside the two feature windows.
The attached PoC reproduces this behavior and shows that the PHP interpreter still successfully executes the sample.
Because this is my first time handling a security issue through a public issue tracker, I was not sure whether including the full PoC here would be appropriate, so I have not attached it for now.