Fixing 1C-Bitrix website vulnerabilities

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

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:

  1. Isolate: put the site in maintenance mode or block external access
  2. Find malicious code:
find /var/www -name "*.php" -exec grep -l "base64_decode\|eval\|system\|exec" {} \;
  1. Analyze modification timestamps: files changed after the last deployment date are suspects
  2. Compare with a clean distribution: download a clean Bitrix build and compare core files using diff -r
  3. Rotate all credentials: administrator passwords, API keys, database password, FTP access
  4. 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 inotifywait or 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.