Vulnerability Remediation for 1C-Bitrix Sites
Vulnerability remediation is not a one-time task. It is a process: find, classify, fix, verify for regressions, and close the vector that allowed the issue to arise. Most incidents on Bitrix sites occur not because of vulnerabilities in the core, but due to outdated custom components, incorrect file permissions, and hardcoded credentials.
Classifying Vulnerabilities in Bitrix Projects
XSS (cross-site scripting) — the most common type. Source: outputting data from $_GET/$_POST without escaping in custom components and templates. Check:
// Vulnerable:
echo $_GET['search'];
// Correct:
echo htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8');
// Or via Bitrix D7:
echo \Bitrix\Main\Text\HtmlFilter::encode($_GET['search']);
Reflected XSS in the search page URL is a typical attack vector. Check all URL parameters that are rendered in the template.
SQL injection — largely obsolete when using the D7 ORM, but still present in legacy components using $DB->Query():
// Vulnerable:
$DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $_POST['login'] . "'");
// Correct:
$DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $DB->ForSql($_POST['login']) . "'");
PHP injection via file upload — missing extension validation in custom upload forms. A file named shell.php.jpg may be renamed and executed.
IDOR (Insecure Direct Object References) — requests like /order/?ID=12345 without verifying that the order belongs to the current user. This is handled in standard Bitrix components but often not in custom ones.
Infection Cleanup
If the site is already compromised — follow this sequence:
- Isolate: put the site in maintenance mode or block external access
- Find malicious code:
find /var/www -name "*.php" -exec grep -l "base64_decode\|eval\|system\|exec" {} \;
- Analyze modification timestamps: files changed after the last deployment date are suspects
-
Compare with a clean distribution: download a clean Bitrix build and compare core files using
diff -r - Rotate all credentials: administrator passwords, API keys, database password, FTP access
- Update core and modules to current versions
The b_security_log table — review events leading up to the infection. The IP used to exploit the vulnerability is often visible there.
Closing Attack Vectors
File permissions — after cleanup:
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 440 /var/www/html/bitrix/.settings.php
chmod 440 /var/www/html/bitrix/php_interface/dbconn.php
Block PHP execution in upload/:
location ~* /upload/.*\.php$ {
deny all;
return 404;
}
Update dependencies — if the project uses Composer, run composer audit to check for known CVEs in dependencies.
Real-World Case
A large online store, Business Plus edition. Symptom: occasional redirects to third-party sites, but only for search engine bots (User-Agent-based). The Bitrix scanner showed nothing. Analyzing files by modification date revealed a modified /bitrix/modules/main/include/prolog.php — injected with code that checked the User-Agent and performed a redirect. Additionally: a backdoor in /bitrix/components/bitrix/main.include/component.php. Entry vector — a compromised FTP password from 2019 that had leaked through another service.
Fix: restoring core files from the reference distribution, rotating all passwords, enabling two-factor authentication for FTP and SSH, switching to SFTP with key-based authentication instead of passwords.
Preventive Measures After Remediation
-
File integrity monitoring: configure
inotifywaitor use the "Integrity Control" module in Bitrix - WAF: enable and configure the proactive filter in active mode
- Regular updates: subscribe to Bitrix security update notifications
- Access restrictions: FTP/SSH only from specific IPs, deploy via CI/CD without persistent FTP access
Delivery Time
| Task | Timeline |
|---|---|
| Fixing a specific code vulnerability | 2–4 hours |
| Infection cleanup + audit | 1–2 business days |
| Full hardening after an incident | 3–5 business days |
Timelines depend on the extent of the infection, the volume of custom code, and the availability of clean backups from before the infection.







