🏁 Script executed:

git ls-files | head -20

Repository: lightspeed-core/lightspeed-stack

Length of output: 782

🏁 Script executed:

find . -maxdepth 2 -name "requirements*.txt" -o -name "pyproject.toml" -o -name "setup.py" | head -20

Repository: lightspeed-core/lightspeed-stack

Length of output: 239

🏁 Script executed:

wc -l requirements.hashes.source.txt 2>/dev/null || echo "File not found, searching for it..."
fd -n "requirements.*" . --type f

Repository: lightspeed-core/lightspeed-stack

Length of output: 358

🏁 Script executed:

# Read the specific lines mentioned in the review comment from requirements.hashes.source.txt
sed -n '20,22p; 196,198p; 202,204p; 483,493p; 494,515p; 561,563p; 702,704p; 717,719p; 766,768p' requirements.hashes.source.txt

Repository: lightspeed-core/lightspeed-stack

Length of output: 4043

🏁 Script executed:

# Also check the beginning to see the file structure
head -30 requirements.hashes.source.txt

Repository: lightspeed-core/lightspeed-stack

Length of output: 1919

🏁 Script executed:

# Read pyproject.toml to check dependencies as per the learning
cat pyproject.toml

Repository: lightspeed-core/lightspeed-stack

Length of output: 6008

🏁 Script executed:

#!/bin/bash
# Verify package versions on PyPI
packages=(
  "cachetools==7.0.0"
  "litellm==1.81.6"
  "llama-stack-api==0.4.4"
  "protobuf==6.33.5"
  "psutil==7.2.2"
  "rich==14.3.2"
  "tqdm==4.67.2"
  "wcwidth==0.5.3"
  "pyjwt==2.11.0"
)

echo "=== Verifying PyPI versions ==="
for pkg in "${packages[@]}"; do
  name="${pkg%==*}"
  version="${pkg#*==}"
  echo "Checking $name $version..."
  
  # Use curl to check PyPI JSON API
  response=$(curl -s "https://pypi.org/pypi/$name/$version/json" 2>/dev/null)
  
  if echo "$response" | grep -q "\"version\": \"$version\"" 2>/dev/null; then
    echo "✓ FOUND: $name $version"
  else
    # Try alternative check
    if echo "$response" | grep -q "\"name\": \"$name\"" 2>/dev/null; then
      echo "✓ FOUND: $name $version"
    else
      echo "✗ NOT FOUND: $name $version"
    fi
  fi
done

Repository: lightspeed-core/lightspeed-stack

Length of output: 600

🌐 Web query:

security vulnerabilities cachetools 7.0.0 CVE

💡 Result:

• There is no “cachetools 7.0.0” release for the PyPI package cachetools (the project’s current releases are in the 6.x line; PyPI shows recent 6.2.x releases, e.g., 6.2.6). [1]
• No CVEs / direct vulnerabilities are currently associated with cachetools in major vulnerability trackers (e.g., Safety DB and Snyk both report no known security issues for cachetools). [2] [3]

If you meant CacheToolsUtils (a different PyPI project that does have a 7.0 series), say so and I’ll check CVEs/advisories for that package/version specifically. [4]

Sources: [1] [2] [3] [4]

🌐 Web query:

security vulnerabilities litellm 1.81.6 CVE

💡 Result:

No public CVE records I found list LiteLLM 1.81.6 as affected. The published LiteLLM CVEs (so far) are scoped to older versions (either specific versions or “before” / “up to” ranges) that are well below 1.81.6, e.g.:

• CVE-2024-5225 (SQL injection): affected up to (including) 1.40.2. [1]
• CVE-2024-2952 (SSTI): affected up to (excluding) 1.34.42. [2]
• CVE-2024-4888 (arbitrary file deletion): affected up to (excluding) 1.35.19. [3]
• CVE-2024-9606 (API key leakage in logs): affects LiteLLM before 1.44.12. [4]
• CVE-2025-0628 (improper authorization / privilege escalation): affects all versions before 1.61.15 (fixed in 1.61.15). [5]
• CVE-2025-11203 (health endpoint API_KEY disclosure): vendor advisory indicates it’s fixed in 1.63.14. [6]
• Additional CVEs tied to specific older versions: 1.27.14 (CVE-2024-4890), 1.34.34 (CVE-2024-5710), 1.38.10 (CVE-2024-6587), 1.52.1 (CVE-2025-0330). [7]

If you want, paste your deployment mode (Python library vs proxy server) and enabled endpoints, and I can map which of the above are relevant attack-surface-wise even if your version is newer.

Sources: [1] [2] [3] [4] [5] [6] [7]

🌐 Web query:

security vulnerabilities protobuf 6.33.5 CVE

💡 Result:

protobuf 6.33.5 (PyPI) is primarily relevant because it fixes the most recent protobuf Python CVE:

• CVE-2026-0994 (DoS via recursion depth bypass in google.protobuf.json_format.ParseDict() with nested Any)
  Affects protobuf ≤ 6.33.4; upgrading to 6.33.5 removes exposure. The CVE description is in NVD. [1][2][3]

Other notable recent protobuf-python CVE (already fixed well before 6.33.5):

• CVE-2025-4565 (DoS via unbounded recursion in the pure-Python backend when parsing crafted protobuf data)
  Patched in 6.31.1 (and also 4.25.8 / 5.29.5), so 6.33.5 is not affected. [4]

As of the sources above, there are no additional CVEs specifically reported as affecting protobuf 6.33.5 (it appears as a “fixed/upgrade-to” version for the active recursion-related issue). [2][3]

Sources
[1] NVD – CVE-2026-0994: https://nvd.nist.gov/vuln/detail/CVE-2026-0994
[2] Snyk (protobuf PyPI vuln page showing fix version): https://security.snyk.io/package/pip/protobuf/5.29.0
[3] Resolved Security (affected ≤6.33.4): https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2026-0994
[4] GitHub Security Advisory (GHSA-8qvm-5x2c-j2w7 / CVE-2025-4565): GHSA-8qvm-5x2c-j2w7

🌐 Web query:

security vulnerabilities psutil 7.2.2 CVE

💡 Result:

As of Feb 2, 2026, there are no publicly listed CVEs known to affect psutil 7.2.2.

• psutil 7.2.2 was uploaded to PyPI on Jan 28, 2026. [1]
• Snyk reports “NO KNOWN SECURITY ISSUES” for the latest versions and notes that while psutil has historical vulnerabilities, they do not affect 7.2.2. [2]
• The main widely referenced CVE for psutil is CVE-2019-18874 (double free due to refcount mishandling), which affects psutil through 5.6.5—so it does not apply to 7.2.2. [3]

Sources: [1] PyPI release files for psutil 7.2.2, [2] Snyk psutil package page, [3] NVD entry for CVE-2019-18874.

🌐 Web query:

security vulnerabilities pyjwt 2.11.0 CVE

💡 Result:

As of February 2, 2026, I can’t find any CVE that lists PyJWT 2.11.0 as an affected version. The public CVEs associated with PyJWT in recent years are tied to earlier versions:

• CVE-2024-53861 – Issuer (iss) validation partial-match bug; affected: 2.10.0 only, fixed: 2.10.1. PyJWT 2.11.0 is not affected. [1]
• CVE-2022-29217 – Algorithm confusion / risky algorithm usage when apps accept “all default algorithms”; patch recommended: upgrade to 2.4.0 and explicitly restrict allowed algorithms when decoding. PyJWT 2.11.0 is not affected (it is far newer than the fixed version guidance). [2]
• CVE-2025-45768 – Reported as “weak encryption” in 2.10.1, but the record is explicitly disputed (supplier notes the key length is chosen by the application). It is not clearly established as a library vulnerability affecting later versions, and NVD’s affected configuration shown is 2.10.1. PyJWT 2.11.0 is not listed as affected. [3][4]

Bottom line: No CVE I found currently implicates PyJWT 2.11.0; the main actionable items are “don’t use 2.10.0” (due to CVE-2024-53861) and ensure your application explicitly restricts accepted algorithms when decoding tokens (the core risk described in CVE-2022-29217). [1][2]

Sources: NVD CVE entries and distro trackers. [1][2][3][4]

🏁 Script executed:

# Check if there's a typo and what the actual latest cachetools version is
curl -s "https://pypi.org/pypi/cachetools/json" | grep -o '"version": "[^"]*"' | head -5

Repository: lightspeed-core/lightspeed-stack

Length of output: 58

🌐 Web query:

cachetools latest version PyPI 2026

💡 Result:

The latest cachetools release on PyPI is 6.2.6, uploaded January 27, 2026. [1]