ai.mcpjunction/directory
version 1.0.0
- scanned 2026-10-16
- source github.com/rickstek/mcpjunction
- commit e31b3f847438
- transport streamable-http
- files read 11
- methodology 0.2.0
- ruleset 0.1.1
No tag matching version 1.0.0 was found in this repository, so the scan read the default branch instead. The findings below describe that code, not necessarily the released version.
91
68measured on 65% of this axis
63
75measured on 70% of this axis
29
The evidence
Every deduction below names the artefact that produced it. Nothing on this page was executed: the source was read, never run, and no running server was contacted.
Code Safety
- scripts/pipeline.py:228mcp-python-ssrf-nonliteral-url (medium/low)
An outbound HTTP request is made to a URL that is not a literal. If any part of it is caller-supplied, the server can be steered at internal hosts — cloud metadata endpoints, admin ports, other tenants.
req.add_header("Authorization", f"Bearer {TOKEN}") try: with urllib.request.urlopen(req, timeout=45) as resp: return json.loads(resp.read().decode("utf-8")) except urllib.error.HTTPError as e: - scripts/verify_edge_rules.py:94mcp-python-ssrf-nonliteral-url (medium/low)
An outbound HTTP request is made to a URL that is not a literal. If any part of it is caller-supplied, the server can be steered at internal hosts — cloud metadata endpoints, admin ports, other tenants.
) try: with urllib.request.urlopen(req, timeout=30) as resp: payload = json.loads(resp.read().decode("utf-8")) except urllib.error.HTTPError as exc:
Auth Posture
- authentication_model
source reads a credential header but no enforcing middleware or rejection path was found — `03` §4's "present but optional or trivially bypassable" band
- transport_security
declared endpoint(s) are HTTPS: https://mcpjunction.ai/mcp; scored 80, not 100: `03` §4 reserves 100 for HTTPS *with HSTS*, and an HSTS header can only be seen by connecting, which `04` §9 does not do. This is an unverifiable band, not an observed absence.
- secret_handling
detect-secrets matched 1859 credential-shaped string(s), every one from a keyword or entropy heuristic (Base64 High Entropy String, Hex High Entropy String). Those flag placeholders, variable names and content hashes as readily as credentials, so they do not establish the committed credential `03` §4's 0 asserts, and this sub-check is not scored; Base64 High Entropy String at public/data/mcp_servers.json:55625; Base64 High Entropy String at public/data/mcp_servers.json:62883; Hex High Entropy String at state/lastmod.json:6; Hex High Entropy String at state/lastmod.json:10; Hex High Entropy String at state/lastmod.json:14; Hex High Entropy String at state/lastmod.json:18; Hex High Entropy String at state/lastmod.json:22; Hex High Entropy String at state/lastmod.json:26; Hex High Entropy String at state/lastmod.json:30; Hex High Entropy String at state/lastmod.json:34; …and 1849 more matches
- authorization_granularity
no tool registration was recognised anywhere in the source. An MCP server registers tools by definition, so this is a gap in our detection rather than a server with none, and `03` §4's threshold cannot be applied to it.
Dependency Health
- package-lock.jsonsharp 0.35.4 — GHSA-wq5f-xc86-pv6w
transitive, CVSS 8.9, fixed in 0.35.5
https://osv.dev/vulnerability/GHSA-wq5f-xc86-pv6w - package-lock.jsonhttp-cache-semantics 4.2.0 — GHSA-ch52-4w7c-c8xp
transitive, CVSS 8.7
https://osv.dev/vulnerability/GHSA-ch52-4w7c-c8xp - package-lock.jsonsource-map-js 1.2.1 — GHSA-68fv-2mgg-jv7q
transitive, CVSS 8.7, fixed in 1.2.2
https://osv.dev/vulnerability/GHSA-68fv-2mgg-jv7q - package-lock.jsondevalue 5.9.0 — GHSA-mcm9-63f2-9j32
transitive, CVSS 8.2, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-mcm9-63f2-9j32 - package-lock.jsondevalue 5.9.0 — GHSA-r9w8-h9r3-54w4
transitive, CVSS 8.2, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-r9w8-h9r3-54w4 - package-lock.jsondevalue 5.9.0 — GHSA-x5rw-q4pp-hg5g
transitive, CVSS 8.2, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-x5rw-q4pp-hg5g - package-lock.jsonsvgo 4.0.2 — GHSA-w27v-7q3p-w38r
transitive, CVSS 8.2, fixed in 4.1.0
https://osv.dev/vulnerability/GHSA-w27v-7q3p-w38r - package-lock.jsondevalue 5.9.0 — GHSA-j22f-vq7h-c4qm
transitive, CVSS 7.5, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-j22f-vq7h-c4qm - package-lock.jsonundici 8.10.0 — GHSA-rfgv-xxqx-mfg5
transitive, CVSS 7.5, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-rfgv-xxqx-mfg5 - package-lock.jsonundici 8.10.0 — GHSA-vp8m-p9jh-q5pm
transitive, CVSS 7.4, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-vp8m-p9jh-q5pm - package-lock.jsonundici 8.10.0 — GHSA-w293-vg96-wgc3
transitive, CVSS 7.4, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-w293-vg96-wgc3 - package-lock.jsonundici 8.10.0 — GHSA-2jfj-6hjv-fm6j
transitive, CVSS 6.5, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-2jfj-6hjv-fm6j - package-lock.jsondevalue 5.9.0 — GHSA-4q55-j62x-fr9h
transitive, CVSS 6.3, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-4q55-j62x-fr9h - package-lock.jsondevalue 5.9.0 — GHSA-hx4r-w6wj-j8fg
transitive, CVSS 6.3, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-hx4r-w6wj-j8fg - package-lock.jsonsvgo 4.0.2 — GHSA-4vpr-x523-8j87
transitive, CVSS 6.1, fixed in 4.1.0
https://osv.dev/vulnerability/GHSA-4vpr-x523-8j87 - package-lock.jsonundici 8.10.0 — GHSA-3wwx-pv8p-q78v
transitive, CVSS 5.9, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-3wwx-pv8p-q78v - package-lock.jsonundici 8.10.0 — GHSA-3xpg-4rpp-hhhm
transitive, CVSS 5.9, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-3xpg-4rpp-hhhm - package-lock.jsonundici 8.10.0 — GHSA-pmjh-fq2x-6v4x
transitive, CVSS 5.9, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-pmjh-fq2x-6v4x - package-lock.jsonundici 8.10.0 — GHSA-rx4f-c7p8-82vq
transitive, CVSS 5.9, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-rx4f-c7p8-82vq - package-lock.jsondevalue 5.9.0 — GHSA-9rgm-9g3h-6x36
transitive, CVSS 5.3, fixed in 5.9.2
https://osv.dev/vulnerability/GHSA-9rgm-9g3h-6x36 - package-lock.jsonsmol-toml 1.8.0 — GHSA-r4xh-jqrq-34v2
transitive, CVSS 5.3, fixed in 1.9.0
https://osv.dev/vulnerability/GHSA-r4xh-jqrq-34v2 - package-lock.jsonundici 8.10.0 — GHSA-2gqq-gqf2-x968
transitive, CVSS 3.7, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-2gqq-gqf2-x968 - package-lock.jsonundici 8.10.0 — GHSA-8436-99hf-9mmv
transitive, CVSS 3.7, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-8436-99hf-9mmv - package-lock.jsonundici 8.10.0 — GHSA-r53p-7pc4-xj5r
transitive, CVSS 3.7, fixed in 8.10.2
https://osv.dev/vulnerability/GHSA-r53p-7pc4-xj5r - package-lock.jsondevalue 5.9.0 — GHSA-wf3x-273g-mvxv
transitive, CVSS 2.3, fixed in 5.9.3
https://osv.dev/vulnerability/GHSA-wf3x-273g-mvxv
Maintenance
- recency
last commit 2 day(s) before 2026-10-16
- issue_responsiveness
lifetime median (1 issue(s) in the last 6 months, under `03` §5's floor of 3): 9.5 day(s) to first maintainer comment
- release_cadence
this repository publishes neither releases nor version tags
- bus_factor
sole maintainer
- repository_signals
`03` §5 scores this by quartile WITHIN the server's category, which needs a distribution across every scanned server and so cannot be computed while scanning one. It is a post-pass over the crawl and that pass does not exist yet.
Transparency
- license
LICENSE present with no SPDX-License-Identifier tag; identified as 'MIT' from its text
- readme_quality
README.md: configuration documented (+25), states what the server does in the first 200 words (+20)
- declared_scopes
neither the README nor the MCP manifest documents what the server accesses or what side effects it has
- changelog
no CHANGELOG in the fetched source. `03` §7's partial credit for tagged releases carrying release notes is not applied here — that needs the forge API, which this check does not call
- security_contact
no SECURITY.md and no disclosure contact in the README, so a finder has no route to report a vulnerability privately
Contest a finding
Every number here comes from a rule reading published source, and rules get things wrong. If something on this page is incorrect — or correct but mitigated by a check the rule cannot see — open an issue and we answer it in writing. A finding we got wrong is removed and the rule is fixed; one that stands is answered on the record.
Anyone can file: the maintainer, a researcher who disagrees with the classification, or a user who tested the server and could not reproduce it. Name this server and the rule or advisory ID shown beside the finding above. We aim to reply within five business days and to resolve within ten.