The German Magix Software GmbH rewarded me with a Hall of Fame listing and a free Magix Music Maker 2014 Premium license for my reports of several serious security issues in the online infrastructures of and, which could be used to break both sites entirely:


At this point, I’d like to thank the Magix Security Team for their really fast and always transparent responses and the good coordination process as a whole. This is a perfect example of how the communication between the bug bounty operator and the researcher can satisfy both parties. The fixes for the critical vulnerabilities (RCE, SQLi, LFI) were implemented quite fast within only a few days after my initial report (!), the fix for the XSS took a bit longer, but it’s still acceptable for a medium-severity issue.

Bug Bounty programs are always a great challenge and sometimes you’re rewarded with pretty cool stuff and great references like this – now here’s a short write-up about the discovered vulnerabilities, which already have been fixed by Magix.

Remote Code Execution on

This is the most dangerous flaw, I’ve found while working on this bug bounty program. I’ve discovered a script, that allows an attacker to upload zip files via a HTTP POST request. The script accepts any zip file, renames it to some temporary name and finally extracts the .zip file to a worker directory without checking if the zip file contains a valid file. Additionally, the extracted contents were accessible via www – I think the problem is quite obvious.

To prove the exploitability to Magix, I wrote a short Python script. The following snippet shows how the quite handy Python ZipFile function can be used to dynamically generate a zip file in memory. The .zip file contains one single file named “/tmp/test.php” with a custom PHP payload.

In case of Magix, the target script echoes some additional (and hazardous) debugging output after POSTing an arbitrary zip file: looks like Magix missed to deactivate this output – without this I wouldn’t have probably found this flaw 🙂


Since the debugging output also discloses the full-path of the extracted file, this leads to a nice RCE condition:


Now imagine an attacker who’d upload some malicious C99…

SQL Injection on

This vulnerability is more or less based on the same condition like the previously described RCE flaw. If the zip file contains a specially prepared .ini file, the same script, that is responsible for the RCE flaw, uses the .ini values unfiletered in a SQL query:


Local File Inclusion on

A local file inclusion could become as dangerous as a RCE flaw, because an attacker may read sensitive system files like /etc/passwd:


…and if you’ve got a lazy sysadmin who likes to chmod 777 on files and directories, even more might by revealed 😉

Cross-Site Scripting on

OK – I promised not to write about a XSS in detail anymore, so I’ll leave you with the PoC screenshot:


A real happy day for bug bounty hunters and Magix!

Magix Bug Bounty: (RCE, SQLi) and (LFI, XSS)
Tagged on:                     

3 thoughts on “Magix Bug Bounty: (RCE, SQLi) and (LFI, XSS)

  • June 2, 2018 at 2:23 am

    hi , can i ask u something like how can u find has LFI vuln? are u using web discover tools like dirsearch and after u find out something with info.php < something like that , and then u do parameters brute force or u just using burp spider and find the link look like has LFI vuln and u test it? sorry , becuase im new , i was learn hacking 2 months

    • June 4, 2018 at 6:54 am

      In this specific case I have just watched the traffic that the actual fat-application on Windows was generating and did some basic testing on it, so there was no need to perform brute-force of any kind. However, yes – usually I do use a lot of brute-force techniques to find both files/directories as well as parameters.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.