Bump ejs from 3.1.6 to 3.1.8 in /subhub-link-checker

[dependabot]

Bumps ejs from 3.1.6 to 3.1.8.

Release notes

Sourced from ejs's releases.

v3.1.8

Version 3.1.8

v3.1.7

Version 3.1.7

Commits

• 5126ff5 Version 3.1.8
• 7d5a1c6 Merge branch 'main' of github.com:mde/ejs into main
• 551949d Minor mitigation
• 66f7471 Merge pull request #664 from netcode/patch-1
• 820855a Version 3.1.7
• 076dcb6 Don't use template literal
• faf8b84 Skip test -- error message vary depending on JS runtime
• c028c34 Update packages
• 839ad20 Update SECURITY.md
• c040180 Update README.md
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

In general, the fix is to explicitly declare the minimal GITHUB_TOKEN permissions required by the workflow, either at the workflow root (applies to all jobs) or on the specific job. For a linting workflow that only checks out code and runs local tooling, contents: read is typically sufficient: the workflow needs to read the repository contents but does not need to write to it or manage other resources.

The best fix here, without changing functionality, is to add a permissions block at the workflow root (between name: and on:) specifying contents: read. This documents and enforces least privilege for all jobs in this workflow. No code in steps needs changes, and no additional permissions appear required by the existing steps. Concretely, in .github/workflows/linting.yml, insert:

permissions:
  contents: read

right after line 1 (name: Lint). No imports, methods, or other definitions are needed, since this is purely a YAML configuration change inside the workflow file.

In general, the fix is to add an explicit permissions block following the principle of least privilege, either at the workflow root (applies to all jobs) or under the specific job (sentry-release). This workflow checks out code and calls an external Sentry action; it does not modify repository contents, issues, or pull requests, so contents: read is a suitable minimal permission. No other scopes (issues, pull-requests, etc.) appear necessary.

The best fix without changing functionality is to add permissions: contents: read at the workflow root, directly under the name (line 1) and before the on: block. This will apply to sentry-release and any future jobs added to the workflow unless they override permissions. No imports or other definitions are needed, just the YAML keys.

Specifically, in .github/workflows/sentry.yml, insert:

permissions:
  contents: read

after line 1 (name: Sentry Release) and before line 3 (on:). All existing steps remain unchanged.

In general, to fix log injection when logging user-controlled data, you should sanitize the data before logging. For plain text logs, the minimal effective step is to strip newline and carriage return characters so an attacker cannot inject additional log lines. Optionally, you can also truncate excessively long input.

For this specific case in hub-search-proxy/handler.js, the best minimal fix is to sanitize event.body before interpolating it in the log message. We can do this inline by creating a sanitized variable that removes \r and \n from event.body and then log that instead. This avoids changing any behavior of the rest of the function, which still parses the original event.body with JSON.parse. No new imports or external libraries are required.

Concretely:

• In module.exports.search, around line 53, replace console.log(\Received query: ${event.body}`);` with:
  • Create const safeBody = String(event.body).replace(/[\r\n]/g, '');
  • Log safeBody instead of event.body.

No other lines need to be changed.