ai.lumify/sports-intelligence
version 1.0.1
- scanned 2026-10-16
- source github.com/lumifyai/lumify
- commit f43af0fb7e78
- transport streamable-http
- files read 60
- methodology 0.2.0
- ruleset 0.1.1
No tag matching version 1.0.1 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
80measured on 65% of this axis
46
76measured on 90% of this axis
35
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
- clients/lumify-sdk-python/lumify/_transport.py:72mcp-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: resp = urllib.request.urlopen(request, timeout=timeout) except urllib.error.HTTPError as exc: # A real HTTP response with a non-2xx status — read it and let the - clients/lumify-sdk-python/lumify/sse.py:126mcp-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: return urllib.request.urlopen(request, timeout=read_timeout) except urllib.error.HTTPError as exc: body = exc.read().decode("utf-8", "replace")
Auth Posture
- authentication_model
credential requirement present; enforcement partially evidenced
- transport_security
declared endpoint(s) are HTTPS: https://lumify.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 36 credential-shaped string(s), every one from a keyword or entropy heuristic (Secret Keyword). 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; Secret Keyword at README.md:28; Secret Keyword at README.md:102; Secret Keyword at clients/crewai-lumify/tests/test_connection_config.py:186; Secret Keyword at clients/langchain-lumify/README.md:61; Secret Keyword at clients/langchain-lumify/tests/test_connection_config.py:188; Secret Keyword at clients/llamaindex-lumify/README.md:62; Secret Keyword at clients/llamaindex-lumify/docs/lumify.md:42; Secret Keyword at clients/llamaindex-lumify/tests/test_connection_config.py:209; Secret Keyword at clients/lumify-mcp/README.md:77; Secret Keyword at clients/lumify-sdk-python/tests/test_async_client.py:131; …and 26 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
- examples/scoreboard/package-lock.jsonproxy-addr 2.0.7 — GHSA-jqcg-44mw-7w3h
transitive, CVSS 9.1, fixed in 2.0.8
https://osv.dev/vulnerability/GHSA-jqcg-44mw-7w3h - clients/n8n-nodes-lumify/package-lock.jsonbraces 3.0.3 — GHSA-vfj7-8cjw-p6xm
transitive, CVSS 8.7
https://osv.dev/vulnerability/GHSA-vfj7-8cjw-p6xm - clients/n8n-nodes-lumify/package-lock.jsonform-data 4.0.4 — GHSA-hmw2-7cc7-3qxx
transitive, CVSS 8.7, fixed in 4.0.6
https://osv.dev/vulnerability/GHSA-hmw2-7cc7-3qxx - clients/n8n-nodes-lumify/package-lock.jsonlodash 4.17.23 — GHSA-r5fr-rjxr-66jc
transitive, CVSS 8.1, fixed in 4.18.0
https://osv.dev/vulnerability/GHSA-r5fr-rjxr-66jc - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 1.1.16 — GHSA-6j4f-fj2g-mc7p
transitive, CVSS 7.5, fixed in 1.1.19
https://osv.dev/vulnerability/GHSA-6j4f-fj2g-mc7p - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 2.1.2 — GHSA-6j4f-fj2g-mc7p
transitive, CVSS 7.5, fixed in 2.1.5
https://osv.dev/vulnerability/GHSA-6j4f-fj2g-mc7p - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 5.0.7 — GHSA-6j4f-fj2g-mc7p
transitive, CVSS 7.5, fixed in 5.0.10
https://osv.dev/vulnerability/GHSA-6j4f-fj2g-mc7p - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 1.1.16 — GHSA-mh99-v99m-4gvg
transitive, CVSS 7.5, fixed in 1.1.17
https://osv.dev/vulnerability/GHSA-mh99-v99m-4gvg - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 2.1.2 — GHSA-mh99-v99m-4gvg
transitive, CVSS 7.5, fixed in 2.1.3
https://osv.dev/vulnerability/GHSA-mh99-v99m-4gvg - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 5.0.7 — GHSA-mh99-v99m-4gvg
transitive, CVSS 7.5, fixed in 5.0.8
https://osv.dev/vulnerability/GHSA-mh99-v99m-4gvg - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 1.1.16 — GHSA-qhr7-859c-m2p7
transitive, CVSS 7.5, fixed in 1.1.20
https://osv.dev/vulnerability/GHSA-qhr7-859c-m2p7 - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 2.1.2 — GHSA-qhr7-859c-m2p7
transitive, CVSS 7.5, fixed in 2.1.6
https://osv.dev/vulnerability/GHSA-qhr7-859c-m2p7 - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 5.0.7 — GHSA-qhr7-859c-m2p7
transitive, CVSS 7.5, fixed in 5.0.11
https://osv.dev/vulnerability/GHSA-qhr7-859c-m2p7 - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 1.1.16 — GHSA-rgw5-rvv9-x895
transitive, CVSS 7.5, fixed in 1.1.18
https://osv.dev/vulnerability/GHSA-rgw5-rvv9-x895 - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 2.1.2 — GHSA-rgw5-rvv9-x895
transitive, CVSS 7.5, fixed in 2.1.4
https://osv.dev/vulnerability/GHSA-rgw5-rvv9-x895 - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 5.0.7 — GHSA-rgw5-rvv9-x895
transitive, CVSS 7.5, fixed in 5.0.9
https://osv.dev/vulnerability/GHSA-rgw5-rvv9-x895 - clients/n8n-nodes-lumify/package-lock.jsonjs-yaml 4.3.0 — GHSA-2883-xcg3-v3hh
transitive, CVSS 7.5, fixed in 4.3.2
https://osv.dev/vulnerability/GHSA-2883-xcg3-v3hh - clients/n8n-nodes-lumify/package-lock.jsonjs-yaml 4.3.0 — GHSA-5p4m-2wfm-xmqj
transitive, CVSS 7.5, fixed in 4.3.1
https://osv.dev/vulnerability/GHSA-5p4m-2wfm-xmqj - clients/n8n-nodes-lumify/package-lock.jsonuuid 10.0.0 — GHSA-w5hq-g745-h8pq
transitive, CVSS 7.5, fixed in 11.1.1
https://osv.dev/vulnerability/GHSA-w5hq-g745-h8pq - clients/n8n-nodes-lumify/package-lock.jsonlodash 4.17.23 — GHSA-f23m-r3pf-42rh
transitive, CVSS 6.5, fixed in 4.18.0
https://osv.dev/vulnerability/GHSA-f23m-r3pf-42rh - examples/scoreboard/package-lock.jsonqs 6.15.3 — GHSA-4mjr-xmp4-gh2g
transitive, CVSS 6.3, fixed in 6.16.0
https://osv.dev/vulnerability/GHSA-4mjr-xmp4-gh2g - examples/scoreboard/package-lock.jsonqs 6.15.3 — GHSA-x5fp-wj9c-mxmx
transitive, CVSS 6.3, fixed in 6.16.0
https://osv.dev/vulnerability/GHSA-x5fp-wj9c-mxmx - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 1.1.16 — GHSA-q2hr-2g5m-vwhr
transitive, CVSS 5.3, fixed in 1.1.21
https://osv.dev/vulnerability/GHSA-q2hr-2g5m-vwhr - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 2.1.2 — GHSA-q2hr-2g5m-vwhr
transitive, CVSS 5.3, fixed in 2.1.7
https://osv.dev/vulnerability/GHSA-q2hr-2g5m-vwhr - clients/n8n-nodes-lumify/package-lock.jsonbrace-expansion 5.0.7 — GHSA-q2hr-2g5m-vwhr
transitive, CVSS 5.3, fixed in 5.0.12
https://osv.dev/vulnerability/GHSA-q2hr-2g5m-vwhr
Maintenance
- recency
last commit 43 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): 3.9 day(s) to first maintainer comment
- release_cadence
released 6 day(s) ago (by tags), inside `03` §5's 30-day window
- bus_factor
no author reached `03` §5's 5-commit bar in the last 12 months (1 contributor(s) with fewer) — scored at §5's weakest described band, which the section defines for a quiet 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: installation instructions (+25), 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.