27 sierpnia 2026 VulnCheck opublikował serię podatności dotyczących ekosystemu MCP i narzędzi używanych przez agentów AI. Numery tworzą niemal ciągły blok — CVE-2026-81091 do CVE-2026-81102. Po weryfikacji jest ich 12. Jeszcze ciekawsze są timestampy: cała seria została opublikowana w mniej niż dziewięć sekund. To prowokuje pytanie: czy automatyzacja procesu CVE zaczyna produkować podatności szybciej, niż ekosystem jest w stanie je poprawnie zrozumieć? Odpowiedź nie brzmi jednak „automatyczne CVE są złe” — to byłoby zbyt proste.
Co właściwie zostało opublikowane?
Seria obejmuje bardzo różne klasy problemów — to nie jedna luka sklonowana 12 razy:
python_code_executor, CVSS v4 9.3.Widać wspólny wzorzec
Kilka podatności krąży wokół podobnego problemu:
MCP rozwijał się jako mechanizm pozwalający agentowi korzystać z lokalnych narzędzi. Ale „localhost” nie jest automatycznie granicą bezpieczeństwa. Jeśli browser może wykonać request do usługi przez DNS rebinding, lokalny MCP server staje się zdalnie sterowanym API z uprawnieniami użytkownika. A MCP to nie zwykły port — może mieć dostęp do kodu, plików, poczty, Slacka, baz danych, CRM, repozytoriów i cloud API. Dlatego „Missing Authentication” oznacza w praktyce: unauthenticated caller → agent tools → enterprise credentials → internal data/actions.
ToolUniverse: od MCP do RCE
Najmocniejszym technicznie przykładem jest CVE-2026-81096. ToolUniverse udostępniał python_code_executor; kod miał działać w sandboxie, ale walidacja opierała się na denylistach i pozwalała dojść do obiektów Pythona umożliwiających tworzenie procesów. Jednocześnie HTTP/MCP server bindował się do wszystkich interfejsów, miał debugging i nie wymagał auth:
Fix w 1.3.0 dodaje bearer-token authentication, domyślnie binduje do loopback i wzmacnia kontrole sandboxa. Remediation nie zawsze jest pojedynczą zmianą — vendor naprawił kilka warstw defense-in-depth.
Gdzie wchodzi automatyzacja CVE?
Rekordy serii zawierają pole x_generator: engine: vulncheck-endgame — jawny sygnał, że opracowanie CVE jest wspierane automatyzacją. Sam fakt użycia generatora nie oznacza niskiej jakości; wręcz przeciwnie, rekordy mają precyzyjne affected versions, repozytoria, commity, vendor advisories, CVSS v3.1 i v4 oraz techniczne opisy. Problem pojawia się gdzie indziej: automatyzacja zwiększa szybkość publikacji, a wszystkie systemy konsumujące dane aktualizują się z różną prędkością.
Jeden CVE, kilka prawd w różnych momentach
Weźmy CVE-2026-81094. Rekord jasno mówi: < 0.6.3 affected, 0.6.3 naprawia, patch commit wskazany, vendor advisory istnieje. Jednocześnie agregator w sekcji remediation potrafi wyświetlać „No vendor fix or workaround currently provided” — mimo że na tej samej stronie widać fixed boundary. To nie znaczy, że cały rekord jest błędny. To problem denormalizacji i synchronizacji pól: jedna część systemu może być świeża, inna stale.
„Sprzeczne CVSS-y” — nie każdy różny score to sprzeczność
Przykład mcp-router: CVSS v3.1 = 9.1, CVSS v4.0 = 9.3. To nie błąd — to dwa różne standardy i modele scoringu. Tak samo Airtable MCP CLI: 6.5 vs 6.9. VM nie powinien traktować „different score” automatycznie jako „conflicting data”. Powinien przechowywać score: {cvss31: 6.5, cvss40: 6.9} z dokładnym źródłem. Prawdziwy conflict wygląda inaczej: „fixed in 0.6.3” vs „no fix available”, albo „affected only if network mode enabled” vs „all installations exploitable”, albo PR:N u CNA vs PR:L w secondary feed. Wtedy system musi rozstrzygnąć źródło, datę, wersję rekordu i provenance.
CVE nie jest statycznym dokumentem
Kilka godzin po publikacji rekordy otrzymały enrichment CISA ADP/SSVC (dla mcp-router: Exploitation: none, Automatable: yes, Technical Impact: total). CVE żyje:
Jeśli VM pobierze dane o 15:00 i nie aktualizuje rekordu, pracuje na innym obrazie niż system pobierający o 21:00. Dlatego provenance jest obowiązkowe — finding nie powinien zawierać tylko CVSS = 9.3, ale {value, version, source, retrieved_at}. To samo dla affected versions, fix version, KEV, EPSS i exploit status. Bez provenance nie da się odpowiedzieć: skąd wzięliśmy tę decyzję?
Czy VM powinien czekać na NVD?
Nie. Jeśli mamy wysokiej jakości CNA/vendor advisory z affected range, technical detail i fixed version, czekanie na NVD tylko opóźnia remediation. NVD jest ważnym źródłem, ale nie powinno być jedynym gate'em procesu. Jednocześnie CVE z automatycznego generatora nie powinno automatycznie mieć niższego confidence — lepszy model to confidence based on evidence: czy rekord ma vendor confirmation, patch commit, PoC, affected version precision, reproducible description, independent validation. Automation jest informacją o procesie, nie werdyktem jakości.
Grupowanie po root cause
12 CVE tworzy też pytanie: czy każdy powinien trafić do osobnego workflow? Nie zawsze. Kilka można pogrupować jako „MCP HTTP transport insecure defaults → Host validation → DNS rebinding”, inne jako „MCP server exposure → missing authentication”, inne jako „tool execution → sandbox escape”. Dzięki temu VM buduje klasy problemów, nie tylko listę numerów.
Wniosek
Prawdziwe pytanie nie brzmi „czy automatycznie generowane CVE są wiarygodne?”. Powinno brzmieć: czy nasz Vulnerability Management potrafi ocenić jakość i aktualność danych niezależnie od sposobu ich wygenerowania? Bo w 2026 roku problemem nie jest już wyłącznie brak danych — coraz częściej problemem jest to, że danych jest bardzo dużo i pojawiają się szybciej, niż tradycyjne procesy potrafią je właściwie scalić. To wymaga provenance, timestamps, confidence, conflict detection, source hierarchy i re-enrichment.
Powiązane na blogu
- Sandbox działał, render drugi raz — podatności w ekosystemie agentów AI
- „SSRF”, a realnie darmowe zakupy — etykieta ≠ pełna wartość ryzyka
Źródła
- VulnCheck Advisories — MCP batch (27.08.2026) — vulncheck.com
- CVE-2026-81096 — ToolUniverse unauthenticated RCE — vulncheck.com
- Pluto Security — The MCP Debrief — pluto.security
Nota redakcyjna: stan informacji 29 sierpnia 2026, 22:30 CEST. Po weryfikacji timestampów seria obejmuje 12 CVE od CVE-2026-81091 do CVE-2026-81102. Różnice między CVSS v3.1 i v4.0 nie są same w sobie sprzecznością — wynikają ze stosowania różnych wersji standardu. Problem jakości danych dotyczy przede wszystkim synchronizacji, provenance i niespójnych pól między feedami a agregatorami.