What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported cache-poisoning
Minor caution · low confidence
The workflow uses a cache that could be tricked by someone who knows the date pattern, but the risk is low because the cache only holds temporary build files and there's no sign anyone has tried to exploit it.
Technical evidence
Scanner reason: zizmor matched workflow-security rule cache-poisoning in this repository.
Contextual assessment: The cache key uses a weekly date-based timestamp (${{ env.cache_id }}), which is predictable and could allow an attacker with knowledge of the workflow's trigger pattern to potentially poison the cache with malicious mkdocs build artifacts. However, the cache stores only build-time dependencies for documentation deployment, not runtime secrets or user data. The scanner indicates low confidence, and no evidence of an active attacker or concrete exploit path is provided. The attack requires sophisticated control over the CI trigger and the ability to inject malicious packages, which is not demonstrated in the supplied evidence.
Impact: low · Exploitability: unlikely
Developer action: Consider using a more specific cache key that includes a hash of the workflow file or lock file content to reduce predictability and improve cache isolation.
- Scanner
- zizmor 1.28.0
- Rule
- cache-poisoning
- File role
- tooling
- Source
- .github/workflows/ci.yml:70
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a Python setup action by its version number instead of a specific commit. If someone changed what that version number points to, it could run different code. However, this is a common practice for official actions and there is no evidence of tampering.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/setup-python@v5 using a mutable version tag instead of a fixed commit SHA. If the tag were maliciously reassigned, the CI pipeline could execute altered code. However, this is a GitHub official action hosted in the actions organization, which has safeguards against tag rewriting. The workflow runs only on releases and pull request events, and the action is used to set up Python for documentation deployment. No evidence is provided that the action has been compromised or that an attacker can influence the tag resolution. The risk is a standard supply chain best-practice issue rather than an active vulnerability.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a specific commit SHA to ensure supply chain integrity, for example: actions/setup-python@a4c5e6f (actual SHA).
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:67
zizmor reported unpinned-uses
Minor caution · medium confidence
The CI script uses a version tag (like v4) for one of its tools instead of a fixed commit hash. This is a minor best-practice issue but unlikely to cause harm here since the tool is official and the job only runs tests.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses actions/cache@v4 pinned only to a major version tag rather than a specific commit hash. While this is a common practice, a malicious update to the tag could in theory inject untrusted code. However, the action is an official GitHub action and the job has no privileged access or secret handling, so practical exploitability is very low.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions/cache to a specific commit hash for defense-in-depth, though the risk is low.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:32
Dependency advisory GHSA-r28c-9q8g-f849:pkg:29462f87d245964d2c009cb3 applies
Minor caution · high confidence
The project uses a version of a CSS processing tool that has a known security issue. However, this tool is only active during development to prepare the app for deployment and does not run when users interact with the app. There is no evidence that an attacker could take advantage of this issue, so the practical risk is low.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-r28c-9q8g-f849:pkg:29462f87d245964d2c009cb3 to a dependency declared by this repository.
Contextual assessment: The lockfile pins postcss at version 8.5.14, which is subject to advisory GHSA-r28c-9q8g-f849 (high severity). Postcss is a CSS post-processor used at build time by Vite/Vue tooling to transform styles. In a typical frontend deployment, postcss does not run in the browser, so the vulnerable parsing logic is not reachable at runtime. No evidence of an attacker-controlled CSS input path was provided, and the advisory's impact is not realized in this context. Therefore, while the dependency version is known-vulnerable, exposure is not demonstrated.
Impact: low · Exploitability: unlikely
Developer action: Review the advisory GHSA-r28c-9q8g-f849 details. If future build pipelines ever process untrusted CSS input, upgrade postcss to the latest patched version. For typical static builds, no urgent action is needed.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-r28c-9q8g-f849:pkg:29462f87d245964d2c009cb3
- File role
- production
- Source
- talemate_frontend/pnpm-lock.yaml
zizmor reported unpinned-uses
Minor caution · medium confidence
The workflow uses a version tag instead of a specific commit hash for a login action. This is a best practice concern but unlikely to be exploited.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Docker login action referenced as docker/login-action@v3 without a commit SHA. This allows the action maintainer to change the action under the same major version, introducing supply chain risk. However, only runs on release events with a GITHUB_TOKEN, and no evidence of compromise exists.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a full commit SHA for supply chain hardening.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:42
zizmor reported unpinned-uses
Minor caution · medium confidence
This step uses a generic version tag for a Docker login action instead of a specific commit hash. If an attacker were to take over that action and change what the tag points to, they could run malicious code in your workflow.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses docker/login-action@v3 with a major version tag instead of a pinned commit SHA. This exposes the workflow to supply chain risks if the tag is maliciously updated, though the action is widely used and maintained. The GITHUB_TOKEN used in this step grants packages:write permission, which could be abused if an attacker gains control of the action. However, the risk is low due to the action's reputation and the workflow's limited trigger (prep-* branches).
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a specific commit SHA, e.g., uses: docker/login-action@327cd5a3f5f3f4e7c6a0d7a8f9a0b1c2d3e4f5g6 (replace with the actual SHA for v3).
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/test-container-build.yml:37
zizmor reported excessive-permissions
Minor caution · medium confidence
The CI job for running tests doesn't limit what it can do on GitHub. Since it only runs tests and doesn't change any files, this is a minor security hardening issue, not an active danger.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The test job has no explicit permissions block and inherits the default workflow permissions (which may be write for push events). The job only performs checkouts, dependency installation, linting, and tests—no deploy or write operations. An attacker would need another compromise to exploit this, making it a minor hardening gap.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block with `contents: read` to follow the principle of least privilege.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- test
- Source
- .github/workflows/test.yml:10-62
Dependency advisory GHSA-fxqj-rqcc-2cmp:pkg:aca07d40b95977daa7f2c14c applies
Minor caution · high confidence
This is another known issue in the same build-time CSS tool. Since the tool only runs during development, there's no way for an attacker to use this flaw against users of the app. The risk is low.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-fxqj-rqcc-2cmp:pkg:aca07d40b95977daa7f2c14c to a dependency declared by this repository.
Contextual assessment: Postcss version 8.5.14 also matches advisory GHSA-fxqj-rqcc-2cmp (medium severity). The same build-time analysis applies: postcss is a build dependency, not executed at runtime in the browser. No attacker-controlled CSS input path was shown, and the vulnerability is not exploitable in the deployed frontend. Exposure is not demonstrated.
Impact: low · Exploitability: unlikely
Developer action: Review GHSA-fxqj-rqcc-2cmp for details. For typical use, no immediate action is required. If build processes ever accept external CSS, upgrade postcss to a patched version.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-fxqj-rqcc-2cmp:pkg:aca07d40b95977daa7f2c14c
- File role
- production
- Source
- talemate_frontend/pnpm-lock.yaml
Dependency advisory GHSA-2v37-7h3g-55p8:pkg:32565e5915130b51271b4195 applies
Minor caution · high confidence
A tool used to generate random IDs in the app has a known security flaw. However, there's no evidence that an attacker can actually exploit it to cause harm. The risk remains low without a clear way to use this weakness against users.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-2v37-7h3g-55p8:pkg:32565e5915130b51271b4195 to a dependency declared by this repository.
Contextual assessment: Nanoid version 3.3.12 is flagged by advisory GHSA-2v37-7h3g-55p8 (high severity). Nanoid generates random IDs and is used at runtime in the browser for this frontend application. However, the supplied evidence is only a lockfile entry; no runtime code path, attacker-controlled input to nanoid, or actual exploitation scenario was provided. Without evidence of reachability or concrete harm, exposure is not demonstrated. The impact is likely low even if reachable, as ID predictability in a roleplay app is not critical.
Impact: low · Exploitability: unlikely
Developer action: Consult advisory GHSA-2v37-7h3g-55p8 for details. If nanoid is used with attacker-controlled inputs or for security-sensitive IDs (e.g., authentication), upgrade to a patched version. Otherwise, monitor for updates.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-2v37-7h3g-55p8:pkg:32565e5915130b51271b4195
- File role
- production
- Source
- talemate_frontend/pnpm-lock.yaml
zizmor reported unpinned-uses
Minor caution · medium confidence
The checkout step uses a shortcut tag (v4) instead of a specific commit hash. This is a common but not best-practice approach; the risk is very low because it's an official GitHub action and the job doesn't handle secrets.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses actions/checkout@v4 with only a major version tag. As with other unpinned actions, a hypothetical tag takeover could execute arbitrary code. The action is official and the job has no secrets, so risk is minimal but not zero.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a specific commit hash for improved supply-chain resilience.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:18
zizmor reported unpinned-uses
Minor caution · medium confidence
This step uses a generic version tag for a Docker build-and-push action. If the action were compromised, it could alter the built container image or steal access tokens.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses docker/build-push-action@v5 with a major version tag. This is a supply chain risk similar to the other unpinned action. The step pushes container images to GHCR, and an attacker could potentially inject malicious build steps if they compromise the action tag.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a specific commit SHA, e.g., uses: docker/build-push-action@abcdef1234567890 (replace with the actual SHA for v5).
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/test-container-build.yml:44
zizmor reported unpinned-uses
Minor caution · medium confidence
Another unpinned action. A best practice improvement, not an active threat.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Checkout action referenced as actions/checkout@v4 without SHA pin. Same supply chain risk pattern. Only runs on release events.
Impact: low · Exploitability: unlikely
Developer action: Pin checkout action to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:62
zizmor reported unpinned-uses
Minor caution · medium confidence
This step uses a generic version tag for the checkout action. If the action were compromised, it could run malicious code, but it's unlikely.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses actions/checkout@v4 with a major version tag. While this is a widely used action, pinning to a commit SHA is a security best practice to avoid supply chain attacks. The risk is low because the action's maintainers are trusted and the workflow only runs on prep-* branches.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a specific commit SHA, e.g., uses: actions/checkout@b4acde... (replace with the actual SHA for v4).
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/test-container-build.yml:15
zizmor reported unpinned-uses
Minor caution · medium confidence
The caching action is referenced by version tag, which could be swapped out maliciously in theory, but it's a standard GitHub action and no one has tampered with it. This is a minor improvement opportunity.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow references actions/cache@v4 using a mutable version tag. Similar to the setup-python candidate, this is a GitHub official action but pinning to a commit SHA is recommended to prevent supply chain attacks. The cache action is used to cache mkdocs build output, not sensitive data. No evidence of malicious action modification or attacker influence over the cache key composition beyond the predictable date is provided. The risk is best-practice level rather than an active threat.
Impact: low · Exploitability: unlikely
Developer action: Pin the action to a specific commit SHA, for example: actions/cache@v4 should be replaced with the full commit hash from the action's repository.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:70
Dependency advisory GHSA-28wg-ghj8-5hjv:pkg:d681b9f3617b82bd6b835445 applies
Minor caution · high confidence
This is another known issue in the same ID-generation tool. Without proof that an attacker can use it, the danger is not real in practice. The risk is low.
Technical evidence
Scanner reason: OSV-Scanner matched advisory GHSA-28wg-ghj8-5hjv:pkg:d681b9f3617b82bd6b835445 to a dependency declared by this repository.
Contextual assessment: Nanoid version 3.3.12 is also subject to advisory GHSA-28wg-ghj8-5hjv (high severity). The same reasoning applies: the lockfile confirms the version, but no runtime reachability, attacker-controlled input, or concrete harm was demonstrated. In a frontend roleplay application, the practical impact of ID-related vulnerabilities is low and exposure remains undemonstrated.
Impact: low · Exploitability: unlikely
Developer action: Review GHSA-28wg-ghj8-5hjv for specifics. If nanoid is used in contexts where ID predictability could be exploited (e.g., session tokens), upgrade. Otherwise, no urgent action.
- Scanner
- osv-scanner 2.4.0
- Rule
- GHSA-28wg-ghj8-5hjv:pkg:d681b9f3617b82bd6b835445
- File role
- production
- Source
- talemate_frontend/pnpm-lock.yaml
zizmor reported excessive-permissions
Minor caution · medium confidence
The workflow gives broad write permissions to the repository and packages. This is more than necessary for most jobs, but used only during releases.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: Global permissions set to contents: write and packages: write. The workflow only runs on release events for building and pushing a container (packages: write required) and deploying docs (contents: write required). However, granting broad permissions at the top level increases blast radius if a job is compromised. No evidence of compromise.
Impact: low · Exploitability: unlikely
Developer action: Scope permissions per job using permissions: {} blocks for least privilege.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/ci.yml:13
zizmor reported unpinned-uses
Minor caution · medium confidence
The Python setup step uses a version tag (v5) instead of a specific commit hash. This is a minor best-practice issue but unlikely to cause harm here since the tool is official and the job only runs tests.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The workflow uses actions/setup-python@v5 pinned only to a major version tag. While this is a common practice, a malicious update to the tag could in theory inject code. The action is official and the job has no secrets, so practical exploitability is very low.
Impact: low · Exploitability: unlikely
Developer action: Consider pinning actions/setup-python to a specific commit hash for defense-in-depth.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- test
- Source
- .github/workflows/test.yml:21
zizmor reported excessive-permissions
Minor caution · medium confidence
Part of the same broad permissions concern.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: Same permissions issue as the previous candidate targeting the packages: write permission at line 12. These two candidates cover the same permissions block. This candidate is assessed together with candidate d2643887.
Impact: low · Exploitability: unlikely
Developer action: Apply per-job permission scoping.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/ci.yml:12
zizmor reported unpinned-uses
Minor caution · medium confidence
Unpinned action for building and pushing a Docker image. A supply chain hygiene improvement.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Docker build-push-action referenced as docker/build-push-action@v5 without SHA pin. Runs on release events. Supply chain risk similar to other unpinned actions.
Impact: low · Exploitability: unlikely
Developer action: Pin build-push action to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:49
zizmor reported unpinned-uses
Minor caution · medium confidence
Another unpinned checkout action. Best practice to pin.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: Checkout action referenced as actions/checkout@v4 without SHA pin. Same supply chain risk as other checkout instance. Runs in container-build job on release.
Impact: low · Exploitability: unlikely
Developer action: Pin checkout action to a full commit SHA.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/ci.yml:20
Expected scanner matches (11)
zizmor reported artipacked
Expected behavior · low confidence
A security scanner flagged a potential issue with credentials in workflow artifacts, but this workflow doesn't actually use artifacts at all, so there is no risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The zizmor artipacked rule flags credential persistence through artifacts, but this workflow does not use actions/upload-artifact or any artifact-related steps. The flagged line 20 is a standard checkout action with no artifact upload. No evidence of credential exposure exists.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/ci.yml:20
JavaScript analysis reported javascript.xray.unsafe-regex
Expected behavior · high confidence
This line uses a regular expression to check whether a color code looks valid (like "#ff6600" or "#ff6600aa"). The pattern is safe and won't crash the program even if someone types a very long or tricky input. It's just a normal color validation used when drawing a color picker in the user interface.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex in this repository.
Contextual assessment: The regex `/^#[0-9a-fA-F]{6}([0-9a-fA-F]{2})?$/` is used to validate hex color codes (6 or 8 hex digits with leading `#`). It contains an optional group `([0-9a-fA-F]{2})?` after a fixed 6‑character match. This pattern does not create exponential backtracking because the preceding `{6}` is an exact quantifier with no repetition overlap; any input that matches the first six hex characters will either match exactly two more or fail immediately. The regex is anchored and uses only character classes, making its runtime linear relative to input length. No ReDoS vulnerability is present.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
- Rule
- javascript.xray.unsafe-regex
- File role
- production
- Source
- talemate_frontend/src/utils/litegraphUtils.js:340
zizmor reported artipacked
Expected behavior · low confidence
Another false alert from the artifact credential scanner; this workflow doesn't use artifacts.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: Same as previous artipacked candidate. The flagged line 62 is a checkout action in the deploy-docs job. No artifact storage or credential leakage mechanism exists in this workflow.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/ci.yml:62
OpenGrep reported tavernkeeper.dynamic-execution.python-eval-or-shell
Expected behavior · high confidence
This line just clears the terminal screen when the program starts. It's like typing 'clear' in a terminal yourself. The command is fixed and cannot be changed by an attacker, so it's safe.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.python-eval-or-shell in this repository.
Contextual assessment: The call os.system("cls" if os.name == "nt" else "clear") on line 345 executes a hardcoded platform-specific terminal clear command at server startup. The command string is static and contains no user-controllable input, interpolation, or configuration variable. It is invoked only once during normal startup when the --backend-only flag is not set. This pattern is a conventional cross-platform screen-clearing idiom and does not expose any injection surface.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.python-eval-or-shell
- File role
- production
- Source
- src/talemate/server/run.py:345
JavaScript analysis reported javascript.xray.unsafe-regex
Expected behavior · high confidence
This line contains a regular expression that reads duration strings like 'PT30M' (30 minutes). The regex is built simply with optional numeric parts and cannot be tricked into slowing down or crashing the browser. It behaves safely for any input.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex in this repository.
Contextual assessment: The regex /^P(?:(\d+)Y)?(?:(\d+)M)?(?:(\d+)W)?(?:(\d+)D)?(?:T(?:(\d+)H)?(?:(\d+)M)?(?:(\d+)S)?)?$/ parses ISO-8601 durations. It is anchored with ^ and $, uses only simple optional capturing groups for digit sequences, and contains no nested quantifiers, overlapping alternations, or repetition that would cause catastrophic backtracking. The pattern is safe and performs linearly on valid or invalid input. JS-X-Ray's unsafe-regex rule is a generic heuristic; it does not apply here because the regex structure avoids ReDoS vulnerability.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1
- Rule
- javascript.xray.unsafe-regex
- File role
- production
- Source
- talemate_frontend/src/utils/time.js:10
OpenGrep reported tavernkeeper.dynamic-execution.python-eval-or-shell
Expected behavior · high confidence
This code runs Python scripts from game scenarios but does so inside a restricted sandbox that blocks dangerous actions. It's a deliberate feature, not a security hole.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.python-eval-or-shell in this repository.
Contextual assessment: The exec() call at line 47 is wrapped by RestrictedPython's compile_restricted() and executes within a restricted globals dictionary that includes only safe functions (safer_getattr, guarded_iter_unpack_sequence, etc.). The project intentionally uses RestrictedPython to allow user-defined scene instructions while limiting dangerous operations. No evidence of a sandbox bypass is provided.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.python-eval-or-shell
- File role
- production
- Source
- src/talemate/game/engine/__init__.py:47
OpenGrep reported tavernkeeper.dynamic-execution.python-eval-or-shell
Expected behavior · high confidence
Like the previous case, this runs code from game modules inside a restricted sandbox. It's a normal part of how the game allows custom behavior without risking security.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.dynamic-execution.python-eval-or-shell in this repository.
Contextual assessment: The exec() call at line 73 is identical in nature to line 47, used in compile_scene_module. It also uses RestrictedPython with the same restricted globals setup. The purpose is to load scene modules safely as part of the game engine. No sandbox escape is demonstrated.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.dynamic-execution.python-eval-or-shell
- File role
- production
- Source
- src/talemate/game/engine/__init__.py:73
zizmor reported artipacked
Expected behavior · low confidence
A security scanner thought this step might save credentials in a build artifact, but the step just checks out the code. There is no artifact creation, so no concern.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked heuristic flagged potential credential persistence through artifacts at line 15, but the step is actions/checkout@v4, which does not upload or create artifacts. The GITHUB_TOKEN is used later in the docker login step, but there is no artifact upload in this workflow. The scanner confidence was low, and no actual risk is demonstrated.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/test-container-build.yml:15
malcontent reported anti-static-xor-terms
Expected behavior · low confidence
A security scanner said a logo image might have hidden data, but we only know the file's name and size, not its actual content. Image files often look like random data to scanners, so this is likely a false alarm.
Technical evidence
Scanner reason: malcontent matched behavioral-analysis rule anti-static-xor-terms in this repository.
Contextual assessment: The scanner flagged a PNG image asset for 'terms obfuscated using xor', but the artifact was only metadata (hash and size) and its raw bytes were not provided. PNG files commonly contain compressed pixel data that static analysis tools may misinterpret as obfuscation. Without inspecting the actual binary content, this finding cannot be confirmed as intentional obfuscation or a security threat. The file is a logo in a legitimate AI roleplay frontend project.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- malcontent 1.25.7
- Rule
- anti-static-xor-terms
- File role
- production
- Source
- talemate_frontend/src/assets/logo-11-final.png
zizmor reported artipacked
Expected behavior · low confidence
The scanner was concerned about credentials being saved in build artifacts, but this workflow never creates or uploads artifacts, so the warning is likely a mistake.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The zizmor artipacked rule flagged actions/checkout at line 18 as potentially storing credentials in artifacts. However, this workflow does not use any upload-artifact step, nor does it handle or expose credentials. The scanner's low confidence and absence of artifact usage indicate a false positive.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- test
- Source
- .github/workflows/test.yml:18
OpenGrep reported tavernkeeper.download-and-execute.shell-pipeline
Expected behavior · high confidence
The installer downloads official Python and Node.js from their official websites. This is normal for setting up the app, just like many other programs do when you install them.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.download-and-execute.shell-pipeline in this repository.
Contextual assessment: Line 107 in file uses curl to download a hardcoded Python embed zip from the official python.org URL. After download, the script extracts the archive and later executes python.exe as part of setting up the Talemate application. The download source is pinned to a specific version from a trusted official domain, and the user initiates the installer manually. No attacker-controlled input or untrusted destination is involved. This is a standard dependency-bundling pattern for a local installer and does not represent a security vulnerability.
Impact: low · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.download-and-execute.shell-pipeline
- File role
- production
- Source
- install.bat:107