Накратко: PHP файл в директорията за качване е сериозен предупредителен сигнал, защото там би трябвало да има само изображения и документи. Никога не отваряйте файла в браузъра, а го четете като текст, проверете времевите печати и собственика и потърсете името на файла в логовете за достъп. Безобидни са обикновено само празни заместители като index.php без съдържание; всичко останало третирайте като възможно проникване.
Защо PHP няма работа в директорията за качване
Директориите за качване са за съдържание, което качват посетители или редактори: изображения, PDF, видео. Потребителят на уеб сървъра може да пише там, иначе качванията не работят. Точно това прави тези директории привлекателни за нападателите. Който може да записва файлове през уязвимост, ги оставя там, където писането е позволено.
Нови PHP файлове в директории за качване или кеш според наличните ни съобщения спадат към общите предупредителни сигнали след проникване. За PHP2Shell няма потвърдени Indicators of Compromise; находката затова не казва нищо през коя уязвимост е дошъл файлът. Как се изграждат сигурно функциите за качване, описва Сигурно реализиране на качване на файлове в PHP.
Дали такъв файл може да причини щети, решава конфигурацията на уеб сървъра. Ако той изпълнява PHP файлове в директорията за качване, всеки оставен там файл става възможно дистанционно управление. Ако изпълнението там е блокирано, файлът остава чуждо тяло, но първоначално без ефект. Много инсталации никога не са настройвали тази блокировка.
Как PHP файл попада в директорията за качване?
За оценката помага познаването на възможните пътища. Всеки води до други последващи въпроси.
| Път | Типичен контекст | Последващ въпрос |
|---|---|---|
| Несигурен формуляр за качване | проверка само на разширението или на типа, обявен от браузъра | Кои формуляри приемат файлове? |
| Уязвимост в добавка или тема | позната слабост в остаряло разширение | Кои разширения са остарели? |
| Откраднати данни за достъп | админ, FTP или хостинг акаунт | Какви влизания е имало напоследък? |
| Изпълнение на код през уязвимост | например в интерпретатора, възможно при PHP2Shell | PHP уязвим ли е бил в периода? |
| Легитимна добавка | заместители, рядко кеш файлове | Принадлежи ли файлът към оригиналния пакет? |
Няколко пътя могат да се съчетаят. Нападател, който изпълнява код през уязвимост, може да остави файла само за да се връща по-удобно по-късно.
Систематично изброяване на находките
Преди да оцените отделен файл, добийте преглед. Командите само четат. Пътищата са примери за WordPress; при други системи пригодете пътя за качване.
# PHP-подобни файлове в директорията за качване с размер, собственик, mtime и ctime
find /var/www/html/wp-content/uploads -type f \
\( -iname "*.php*" -o -iname "*.phtml" -o -iname "*.phar" -o -iname ".htaccess" -o -iname ".user.ini" \) \
-printf '%s Bytes %u m:%T+ c:%C+ %p\n'
# Определяне на типа на файла по съдържание, не по разширение (изображения с PHP съдържание правят впечатление)
find /var/www/html/wp-content/uploads -type f -newermt "2026-10-17" -exec file {} + | grep -viE "image|pdf|video|audio"
Други системи ползват други директории за запис, например fileadmin при TYPO3, images при Joomla или директорията за медия под public при Shopware 6. Добавят се кеш и временни директории на приложението. При multisite инсталации и няколко уебсайта на един сървър има съответно много директории за качване; всяка принадлежи в търсенето.
Подозрителни са и файловете .htaccess и .user.ini в директорията за качване. С тях изпълнението на PHP в тази директория може да се включи отново или конфигурацията да се промени.
PHP файл в папката uploads: правилно тълкуване на находката
Не всяко попадение е еднакво сериозно. Следната класификация помага при първата оценка. Тя не замества задълбочено разследване.
| Находка | Първа класификация |
|---|---|
index.php с нула байта или само коментар |
най-често заместител срещу показване на съдържанието на директорията, сверете с добавката |
| PHP файл със съдържание в месечна папка | голямо подозрение |
Двойно разширение като bild.jpg.php или .php.png |
голямо подозрение, типично маскиране |
Изображение, което според file съдържа PHP код |
голямо подозрение, може да се изпълни чрез включване |
.htaccess или .user.ini в директорията за качване |
подозрение, проверете конфигурацията |
| Файлът принадлежи на потребителя на уеб сървъра, ctime след 17.10. | съответства на проникване през уебсайта |
Четете подозрителните файлове само като текст, например с head -c 2000 datei.php или less. Правят впечатление много дълги редове, кодирани низове и имена на функции като eval или base64_decode. По какво разпознавате замъглен код, показва Разпознаване на замъглен PHP код.
Извикан ли е бил файлът? Поглед в лога
Най-важният въпрос след находката е: използвал ли е някой файла? Отговорът стои в логовете за достъп на уеб сървъра. Потърсете името на файла, и в архивираните логове.
# Извиквания на подозрителния файл в текущите и пакетираните логове (името е пример)
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* 2>/dev/null
zgrep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log*.gz 2>/dev/null
# Само успешни извиквания с IP адрес и момент
grep -h "uploads/2026/10/thumb.php" /var/log/nginx/access.log* | awk '$9 == 200 {print $1, $4, $6, $7}'
Много успешни POST заявки от малко адреси сочат активно използване като уеб шел. Липсата на попадения не означава автоматично отбой, защото логовете могат да са ротирани, изтрити или непълни. Ако уебсайтът работи зад CDN или прокси, други протоколи стоят там; при споделения хостинг хостерът обикновено предоставя логовете за достъп в клиентската зона. Внимавайте освен това за заявки към други нови файлове от същите адреси, защото те често водят до други съставни части. Пазете логовете от 20 октомври. Как да анализирате логовете задълбочено, стои в ръководството Анализ на логовете на уеб сървъра след нападение.
Ако логът показва успешни извиквания на непознат PHP файл, приемете, че има проникване. Запазете файла и логовете, ограничете достъпа до сървъра и проверете дали могат да са засегнати лични данни.
След оценката: правилният ред
- Запазете: Копирайте файла с контролна сума и времеви печати, запазете логовете.
- Изяснете произхода: Проверете формулярите за качване, добавките и периода преди находката.
- Потърсете други съставни части: допълнителни файлове, cron задачи, нови админ акаунти.
- Блокирайте изпълнението: Забранете PHP в директорията за качване на ниво уеб сървър, както е описано в статията Забрана на изпълнението на PHP в директориите за качване.
- Почистете и сменете достъпите: едва тогава премахнете файла и подновете всички пароли.
Как помага PHP SOS конкретно?
- Оценка на находката: Проверяваме файла, без да го изпълняваме, и го класифицираме.
- Изясняване на използването: Анализираме логовете и възстановяваме кой кога е извикал файла.
- Пълно почистване: С премахване на зловреден софтуер търсим всички съставни части, затваряме причината и сменяме достъпите.
- Предотвратяване на повторение: Блокираме изпълнението на PHP в директории за запис и наблюдаваме новите файлове.
Често задавани въпроси
Опасен ли е всеки PHP файл в директорията за качване?
Не всеки. Някои добавки оставят празен index.php, за да не се показва съдържанието на папката. Всичко останало, особено файлове със съдържание, необичайно име или двойно разширение, трябва да третирате като съмнителен случай.
Мога ли да отворя подозрителния файл в браузъра?
Не. Извикване през уебсайта изпълнява кода. Четете файла само като текст на сървъра или в копие, например с less или head.
Как да разбера дали файлът е бил използван?
Потърсете името на файла в логовете за достъп на уеб сървъра. Заявки със статус 200 и метод POST показват, че файлът е бил извикан. Свързаните IP адреси и моменти помагат при по-нататъшното разследване.
Стига ли да изтрия файла и да блокирам PHP в директорията за качване?
И двете са необходими, но не достатъчни. Изяснете допълнително как файлът е попаднал там, потърсете други съставни части и сменете данните за достъп. Иначе нападателят се връща по същия път.