Skip to content
Vulnity Vulnity Docs

File Editor Access/Modification

Alert ID: file_editor_used MITRE ATT&CK: T1055 – Process Injection · T1059 – Command and Scripting Interpreter

Severity / Criticality

Section titled “Severity / Criticality”
LevelCondition
LowEditor access, with a 15-minute cooldown
MediumCSS/JS file modification, possible defacement
CriticalPHP file modification, possible RCE

Why is it considered malicious?

Section titled “Why is it considered malicious?”
  • Theme and plugin editors can enable immediate RCE through PHP modifications.
  • They allow backdoor injection without uploading files.
  • They can alter core files for persistence.
  • They enable defacement through CSS/JS manipulation.
  • There is no good security reason to edit code directly in production.
  • This is a security anti-pattern and should be disabled in production environments.

When does the alert trigger?

Section titled “When does the alert trigger?”
  • Editor access: theme-editor.php or plugin-editor.php, low severity, 15-minute cooldown.
  • Detected file modification: POST with newcontent, severity based on extension.
  • Content analysis: presence of dangerous execution functions (eval, system, exec, base64_decode).
  • Dangerous functions detected: file_get_contents(), include(), require().
  • Suspicious request parameters: PHP superglobals that carry attacker-controlled input (POST, GET, REQUEST).

Technical Indicators (IOCs)

Section titled “Technical Indicators (IOCs)”

In the patterns below, <request-param> stands for any attacker-controlled request superglobal (for example a POST, GET, or REQUEST array access):

TypePattern/Example
file_patterneval(base64_decode(<request-param>));
file_pattern@assert(<request-param>);
file_patterncreate_function('', <request-param>);
file_patternadd_action('init', 'malicious_function');
behaviorAccess to theme-editor.php or plugin-editor.php
behaviorPHP file changes outside planned deployments

Common false positives

Section titled “Common false positives”
  • Developers applying emergency hotfixes, although this is still poor practice.
  • Designers editing CSS in production.
  • Legitimate plugins updating templates through the editor.

Investigation steps

Section titled “Investigation steps”
  1. Confirm the identity of the user who edited the file and review action logs.
  2. Compare the modified file with backups or version control.
  3. Look for obfuscated code or newly added dangerous functions.
  4. Build a timeline: timestamp, IP, number of modified files, and correlation with deployments.
  5. Review access logs for requests targeting the modified files.
Section titled “Recommended mitigations”

Immediate

Section titled “Immediate”

Preventive

Section titled “Preventive”

References

Section titled “References”