absholi7ly/elementor-pro-unauthenticated-arbitrary-file-upload-to-rceCVE-2026-32475 Elementor Pro Forms のファイルアップロードフィールドは、検証とファイル処理を2つの別々のループで行い、空のアップロードエントリ（UPLOAD_ERR_NO_FILE）の処理が異なります。認証されていない攻撃者は、multipart を送信できます。
Elementor Pro Formsのファイルアップロードフィールドは、検証とファイル処理を2つの別々のループで実行し、空のアップロードエントリ（UPLOAD_ERR_NO_FILE）の扱いがそれぞれ異なります。認証されていない攻撃者は、最初の空のファイルパートに続けて同じフィールドのPHPペイロードを含むmultipartリクエストを送信できます。これにより、validation()は早期にリターンする一方、process_field()はPHPファイルを公開ディレクトリ（wp-content/uploads/elementor/forms/.php）へ移動させます。
ターゲットページからpost_id、form_id、field_idを自動的に取得します:
python poc.py -t http://localhost/wp --page-url "http://localhost/wp/?page_id=16" -c "whoami"
または:
python poc.py -t http://localhost/wp --page-id 16 -c "whoami"
インタラクティブセッションを開始します:
python poc.py -t http://localhost/wp --page-id 16 -i
この脆弱性の核心は、ファイルアップロード機構そのものをバイパスすることです。この点は、ローカルのラボ環境でテストする場合も、実際のサーバーに対してテストする場合も変わりません。アップロードフィールドに含まれる空の最初のファイルパート+ PHPペイロードは拡張子検証をバイパスしますが、ファイルは依然としてprocess_field()によって処理されます。このPoCでは、ファイルが正常に書き込まれることを実証しました。これは、まさに前述の説明のとおりです。
ハードコードされたLaragonパスについて:
これは、ローカルでの検証を容易にするためだけに含めたものです。
実際のターゲットでは、ディレクトリのパターンは既知で固定されています:
/wp-content/uploads/elementor/forms/
固定されていないのは、最終的なファイル名です。
Elementorは元のファイル名を保持しません。process_field()では、保存されるファイル名は次のように生成されます:
したがって、shell.phpをアップロードした場合、ファイル名は次のようなものになる可能性があります:
66f3a1c2e9b47.php
格納先:
/wp-content/uploads/elementor/forms/
uniqid()は時刻ベースであり、強力な乱数ではありません。おおよそタイムスタンプ+マイクロ秒に基づいて生成されます。したがって、リモートでファイルを復元することは、アップロードの問題ではなく、ファイル名の発見の問題になります。
たとえば、サーバーのDateヘッダーとリクエストのタイミングに基づくタイミングウィンドウを利用する、アップロード時刻の前後の狭い範囲を検索する、またはフォームが[all-fields]を含むメールを送信する場合は正確なURLを復元する、といった方法が考えられます。
私はこのPoCを、核心的な問題そのもの、すなわち認証なしのファイルアップロードを、明確かつ直接的に証明することに焦点を絞りました。uniqid()の値のリモートでの復元まで完全に説明すると、脆弱性自体を検証するために必要な範囲をはるかに超えてデモが長くなってしまうからです。