bitrix-tools Bitrix Vulnerability Journal Review
Purpose
Use this skill to review a vulnerability journal in the AI-security JSON format, rationally re-score findings for [[1С-Битрикс Управление сайтом]] / boxed Marketplace modules, and produce a corrected journal with deterministic schema validation.
The core distinction is raw journal severity vs BUS-aware triage severity. Never present raw scanner high as the final risk until source permissions, version scope, and exploitability are reviewed.
Expected Input Format
The journal must be JSON with:
- top-level
success data.vulnerabilities[]- each vulnerability containing at least:
filelinetypeseveritydescriptionrecommendationfix
The script preserves all vulnerability fields, changes only severity, and adds a reviewed object.
Required Workflow
- Inspect the journal at a high level:
- count findings by type/severity;
- split
.last_versionfrom versioned update folders like1.10.8; - identify whether current publication triage should focus on
.last_version.
- Run deterministic review and validation:
python3 <skill-dir>/scripts/review_journal.py input.json --output reviewed.json
- Read
data.reviewSummaryfrom the output JSON. - Explain the difference between raw journal severity and reviewed severity.
- If the user asks for a human report, summarize:
- raw counts;
- reviewed counts;
- current
.last_versioncounts; - high-to-low/medium downgrades and why.
Triage Rules
Use the script's categories as the source of truth; the model may add contextual commentary but must not silently override the generated JSON without re-running validation.
| Condition | Reviewed severity |
|---|---|
| IDOR/mass assignment without owner check, available to anonymous/site user, causing privileged or monetary action | high |
| Direct financial business-logic damage without authorization: price/quantity/discount/coupon/bonus manipulation in basket/order/payment sinks | high |
| Confirmed backdoor: suspicious obfuscation plus exec/network/file/exfiltration sink | high; obfuscation alone is not a finding |
| SQL injection | medium unless impact is proven beyond the journal text |
| Cross-privilege stored XSS: lower-privileged data executes in administrator/moderation/order UI | medium |
| Reflected XSS | medium |
| CSRF on meaningful state-changing action | medium |
| Authenticated privilege escalation, authenticated IDOR, session-dependent Open Redirect, limited blind SSRF, weak security-token crypto, sensitive TOCTOU/race | medium |
| OAuth/API-Key/bearer token exposed to frontend | keep at least medium; mention conditional validation if token may be a public ID |
| Stored XSS through trusted Bitrix admin/content editor fields | low hardening unless low-privileged/external source is proven |
Open redirect controlled by trusted content property or mere LocalRedirect usage |
low or not a bug without controllable external URL |
__FILE__/absolute path disclosure |
low |
| Hardcoded default/demo external token | low unless real secret scope is confirmed |
Reviewed Node
Every output vulnerability must include:
oldSeveritynewSeveritychangedcategoryversionScopeversioncurrentVersionRelevanceactionconfidencerationale
Validation Requirement
Validation must be done by scripts/review_journal.py, not by model inspection. Before claiming the corrected journal is valid, run either:
python3 <skill-dir>/scripts/review_journal.py input.json --output reviewed.json
or:
python3 <skill-dir>/scripts/review_journal.py --validate-only reviewed.json
Do not claim the structure is correct unless the script exits successfully.
Common Mistakes
- Treating every raw
highXSS as a final blocker. In BUS, a content editor/admin often already has legitimate ways to publish HTML/JS. - Treating historical update-package findings as current
.last_versionblockers. - Dropping original fields from vulnerability entries. Only
severitymay be replaced; all other original fields must remain unchanged. - Deciding
ACCESS_TOKENexposure by name alone. Confirm whether it is an OAuth/API-Key/bearer token or only a public counter/widget/model ID.