TavernKeeper Scan Report

BF-GitH/bf-ooc-injection

Commit 17ca911 Reviewed

No material or immediate-danger concern was identified in this review.

This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.

0 immediate danger 0 material 9 low

What this review found

No material or immediate-danger item was identified.

Deterministic technical evidence (3)
  • JavaScript analysis reported javascript.xray.prototype-pollution · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: javascript-xray-structured-weakness · Execution scope: runtime

    Source: src/utils/validate.js:76

  • JavaScript analysis reported javascript.xray.prototype-pollution · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: javascript-xray-structured-weakness · Execution scope: runtime

    Source: src/presets/preset-io.js:65

  • JavaScript analysis reported javascript.xray.prototype-pollution · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: javascript-xray-structured-weakness · Execution scope: runtime

    Source: src/state/state.js:90

Contextual expected matches (3)

JavaScript analysis reported javascript.xray.prototype-pollution

Expected behavior · high confidence

The scanner flagged the words associated with a known hack technique, but the code is using them to block that very attack. A character name like __proto__ would be rejected before being used as an object key. No security problem exists.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.prototype-pollution. The match applies to this repository.

Contextual assessment: The scanner matched the literal array ['__proto__', 'constructor', 'prototype'] on line 211 of src/state.js. This is an explicit guard inside setCharacterPreset: the function checks `if (dangerous.includes(characterName)) return;` before using characterName as a key on extensionSettings.characterPresets. The dangerous-key list is a defensive filter that prevents prototype pollution, not a pollution sink. The characterName parameter originates from character selection in SillyTavern, and even if it were attacker-controlled, the guard blocks the dangerous keys.

Impact: none · Exploitability: unlikely

Developer action: No action needed. The flagged line is an active prototype-pollution guard.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.prototype-pollution
File role
production
Source
src/state.js:211

JavaScript analysis reported javascript.xray.prototype-pollution

Expected behavior · high confidence

The scanner flagged the words tied to a known hack, but the code is using them to filter out dangerous keys from imported files. A preset file with a malicious key name would have that key skipped. No security problem is present.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.prototype-pollution. The match applies to this repository.

Contextual assessment: The scanner matched the literal array ['__proto__', 'constructor', 'prototype'] on line 145 of src/utils.js. This is inside validateImportData, which sanitizes user-imported JSON preset files. The function iterates over importData.presets entries with Object.entries (which skips inherited properties) and skips any key found in the dangerousKeys list before assigning to a fresh sanitized object. Each value is also passed through validatePresetData, which constructs a new object from validated fields only. The dangerous-key list is a defensive filter, not a pollution vector. No untrusted key reaches an assignment without being checked and filtered.

Impact: none · Exploitability: unlikely

Developer action: No action needed. The flagged line is part of an active prototype-pollution defense.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.prototype-pollution
File role
production
Source
src/utils.js:145

JavaScript analysis reported javascript.xray.prototype-pollution

Expected behavior · high confidence

The scanner flagged the words related to a known hack, but the code is actually using them defensively to block that exact attack. Importing a preset file with a malicious key name would be rejected here. No security problem is present.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.prototype-pollution. The match applies to this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: none · Exploitability: unlikely

Developer action: No action needed. The flagged line is an active prototype-pollution guard. Ensure future refactoring does not remove this check.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.prototype-pollution
File role
production
Source
src/presets.js:257

Related contextual observations

Safe merge pattern used instead of Object.assign

low risk · high confidence

The code deliberately avoids a risky merge pattern and uses a loop with validation instead, which is the correct approach.

Technical assessment

Lines 247-250 use a for...of loop over Object.entries instead of Object.assign to merge validated presets, with a comment explaining this avoids prototype pollution. This is the correct pattern for merging untrusted keyed data.

Impact: none · Exploitability: unlikely

Developer action: No action needed. This is correct defensive coding.

Sources:

Dangerous-key guard in setCharacterPreset

low risk · high confidence

The code checks a denylist before using a character name as a key, which prevents the attack. This is the correct defensive approach.

Technical assessment

Lines 210-212 define the dangerous-key list and immediately use it as a guard clause that returns early, preventing the subsequent bracket-notation assignment from polluting Object.prototype. This is a correct and proportionate defense.

Impact: none · Exploitability: unlikely

Developer action: No action needed. This is correct defensive coding.

Sources:

Dangerous-key filtering in validateImportData

low risk · high confidence

The code checks every key from an imported file against a denylist and skips any dangerous ones, which prevents the attack. This is the correct approach.

Technical assessment

Lines 149-160 iterate over imported preset keys and skip any key found in the dangerousKeys list before assigning validated data to the sanitized object. Combined with the use of Object.entries and validatePresetData, this prevents prototype pollution from imported JSON.

Impact: none · Exploitability: unlikely

Developer action: No action needed. This is correct defensive coding.

Sources:

Coverage and limitations

JavaScript coverage

Tools

Limitations

Technical scan identity