Insufficient evidence of a trojanized LLM weight backdoor (BadSeek-style) in provided passive data
Finding pentest-2026-06-12-004 · 1e9268df2f6a · discovered by pentest-2026-06-12-controlled-44-3287b226
- Target
- mbarbine/platphormnews-www-prod
- Target URL
- https://platphormnews.com
- Run status
- completed · api-multi-model
- Framework
- llm-pipeline
- Priority score
- 0.0625
- Reachability
- model_assessed_from_passive_recon
- Chain depth
- 1
- PoC available
- no
- Asset
- not recorded
- Discovered
- Jun 12, 2026, 08:45 PM
Description
Your repository is in scope, but the provided target context is limited to public HTTP GET responses (HTML, robots.txt, sitemap(s), llms.txt, and portions of openapi.yaml/health). For the specific attack class “LLM Model Weight Backdoor (llm-model-weight-backdoor)” (e.g., Trojanized open-source weights such as BadSeek with a poisoned-trace influence on downstream ASR), confirming evidence would require at least one of: (1) model artifact identifiers/hashes, (2) model weight provenance/registry and a known-bad version reference, (3) presence of backdoor metadata (e.g., weight-source indicators), (4) audit logs/results showing anomalous behavioral ASR tied to specific trigger traces, or (5) source-code/CI clues showing poisoned weight ingestion or model replacement. None of that is present in the supplied passive HTTP data, so the backdoor cannot be validated or ruled out from this context alone.
Validation
The proposed finding is essentially a scope/evidence statement: the only provided context is passive public HTTP GET responses (HTML, robots.txt, sitemap(s), llms.txt, and partial openapi.yaml/health). For an “LLM Model Weight Backdoor (BadSeek-style)” determination, the hunter listed concrete validation requirements (e.g., model artifact hashes/IDs, provenance/known-bad version references, backdoor metadata, audit results linking anomalous ASR to triggers and specific traces, or CI/source clues for poisoned weight ingestion/replacement). None of those evidentiary artifacts are present in the described passive data. Therefore, the inability to validate or rule out the backdoor from this dataset is justified and not contradicted by any additional evidence.
Remediation
Provide one of the following for evidence-based classification: (a) the exact model name(s)/revision(s) used by the application (from code/lockfiles/CI) and their cryptographic hashes, (b) the source location(s) and integrity verification steps used when downloading weights, (c) any internal model-evaluation outputs that report ASR/behavioral anomalies (including any trigger/trace definitions), or (d) repository files/paths related to model loading (e.g., where weights are referenced or pulled). With those, we can check provenance and compare against known trojaned distributions, and/or validate whether behavior is consistent with a 2%-poisoned-traces/80%+ ASR scenario.
Evidence Boundary
This page shows persisted finding evidence, validator rationale, target context, and run linkage. Raw prompts, raw target responses, provider payloads, secrets, cookies, and authorization headers are not rendered publicly. Use the linked run page for class execution evidence, run logs, cost events, and pipeline errors.