A Claude Code fejlesztői asszisztenst használó felhasználók jelszavakat, API-kulcsokat és más hitelesítési adatokat tettek közzé egy olyan beállításfájlban, amely a korábban jóváhagyott parancsokat tárolja – állítja az Apiiro alkalmazásbiztonsági vállalat kutatása.
A kutatók a .claude/settings.local.json fájl 1122 nyilvános példányában találtak hitelesítési adatokat. A korábbi fájlverziókra és további, fejlesztői ügynökökhöz kapcsolódó állományokra is kiterjedő vizsgálat összesen 2539 különálló titkos adatot azonosított 1994 GitHub-kódtárban. Az Apiiro 63 szervezet érintettségéről számolt be.
A kutatók nem próbálták ki a megtalált belépési adatokat. Egy értesített vállalat ugyanakkor megerősítette, hogy a nyilvánosságra került kulcsa működőképes volt. A közzététel, a hitelesítési adat érvényessége és az azzal elkövetett visszaélés külön megállapítás. Az Apiiro kutatási beszámolója
Az eset a generált programkód minőségén túlmutató problémát jelez. A fejlesztői asszisztensek érzékeny adatokról készíthetnek újabb másolatokat, amikor megjegyzik az engedélyeket, rögzítik a műveleteket vagy fenntartják a projekt munkakörnyezetét. Ezek a kiegészítő fájlok is biztonsági ellenőrzést igényelnek.
Hogyan lesz egy mentett jóváhagyásból adatszivárgási kockázat?
A Claude Code engedélyezési rendszere lehetővé teszi, hogy a fejlesztő egy műveletet egyszeri alkalomra hagyjon jóvá, vagy tartós engedélyt adjon a későbbi végrehajtásokhoz.
Az Anthropic dokumentációja szerint a „Yes, and don’t ask again” lehetőség választásakor a rendszer a projekt .claude/settings.local.json fájljába menthet engedélyező szabályt. A parancssori műveleteknél a szabály vonatkozhat egy pontos parancsra vagy egy megadott mintára illeszkedő parancsokra. A Claude Code engedélyezési dokumentációja
Ez azért lényeges, mert a pontosan eltárolt parancs a benne szereplő jelszót vagy tokent is megőrizheti. A későbbi, szabálynak megfelelő műveletek ezután újabb jóváhagyási kérdés nélkül futhatnak.
Az Apiiro olyan nyilvánosan közzétett engedélyezési szabályokat talált, amelyekben a hitelesítési adatok a jóváhagyott parancs részeként szerepeltek. A nyilvános kitettség akkor alakult ki, amikor a helyi beállításfájl bekerült a GitHubon elérhető kódtárba.
A jóváhagyás mentése és a fájl publikálása két külön lépés. A kényelmi funkció létrehozhatja az érzékeny adat újabb példányát; a verziókezelési vagy közzétételi folyamat pedig ezt a példányt hozzáférhetővé teheti mások számára.
Egy fejlesztő tehát gondosan kizárhatja az eredeti konfigurációs fájlt a verziókezelésből, miközben nem veszi észre, hogy ugyanaz a jelszó egy mentett parancson keresztül egy másik fájlban is megjelent.
Miért kerülhet egy „helyi” beállításfájl a GitHubra?
Az Anthropic különbséget tesz a megosztott projektbeállítások és a személyes, projektenkénti beállítások között.
| Fájl | Rendeltetés | Verziókezelési szempont |
|---|---|---|
.claude/settings.json | A csapat közös projektbeállításai | Szándékosan bekerülhet a kódtárba |
.claude/settings.local.json | Személyes projektbeállítások és mentett jóváhagyások | Helyi használatra szolgál, nem megosztásra |
A jelenlegi dokumentáció szerint amikor a Claude Code először írja a helyi fájlt egy olyan Git-kódtárban, amely még nem zárja ki azt, hozzáadja a megfelelő mintát a fejlesztő globális Git-kizárási fájljához. Kézzel létrehozott helyi beállításfájlnál a dokumentáció külön kéri a kizárás beállítását. A Claude Code beállításfájljainak leírása
A globális kizárás a fejlesztő saját Git-környezetéhez kapcsolódik. A projekt .gitignore fájljában megadott szabály ezzel szemben a kódtárral együtt átadható a többi közreműködőnek.
A Git működésének van azonban egy fontos korlátja: a kizárási szabályok nem vonatkoznak a már követett fájlokra. Ha egy érzékeny állomány korábban bekerült a verziókezelésbe, a .gitignore későbbi módosítása önmagában nem állítja le a követését. A Git hivatalos gitignore-dokumentációja
Ilyenkor a fájlt a Git indexéből is el kell távolítani, és megfelelő kizárási szabályt kell hozzáadni. Ez a jövőbeli változatok közzétételét akadályozhatja meg, a korábbi verziókat azonban nem törli.
A „local” szó a fájlnévben elnevezési szokás, nem hozzáférési korlát. A szervezeteknek a tényleges verziókezelési viselkedést kell ellenőrizniük.
Jelentős jogosultságot biztosító adatok is megjelentek
Az Apiiro által azonosított anyagok között adatbázis-jelszavak, SSH-belépési adatok, forráskód- és csomagkezelő platformok tokenjei, valamint AWS-kulcsok is szerepeltek. Egyes példák adminisztratív jogosultságokra vagy éles rendszerekhez kapcsolódó hozzáférésre utaltak.
Az érintett kódtárakban a helyi beállításfájl első verziókezelésbe kerülése óta eltelt idő mediánja 217 nap volt. A korábbi fájlverziók olyan további adatokat is tartalmaztak, amelyek az aktuális állományokban már nem szerepeltek. Az Apiiro eredményei és történeti vizsgálata
Az egyedi kockázatot az határozza meg, hogy az adott hitelesítési adat milyen műveleteket engedélyez, érvényes-e még, és elérhető-e a hozzá tartozó szolgáltatás.
Egy kizárólag olvasásra jogosító adatbázis-fiók más következményekkel járhat, mint egy rekordok módosítására vagy törlésére képes hozzáférés. Egy csomagközzétételi token szoftverellátási kockázatot teremthet, ha kiadások feltöltését vagy módosítását teszi lehetővé. Egy felhőkulcs pedig a kódtárnál jóval szélesebb erőforráskörhöz adhat hozzáférést.
Ezek lehetséges következmények, nem a kutatásban igazolt káresemények. A különbségtételnek a vizsgálat pontosságát kell segítenie, nem az intézkedések halasztását. A széles jogosultságú, éles környezethez tartozó és közvetlenül elérhető szolgáltatásokhoz használható adatok kiemelt figyelmet igényelnek.
A titokkeresésnek a parancsokba ágyazott jelszavakat is fel kell ismernie
Az Apiiro a megtalált fájlokon a Gitleaks és a TruffleHog eszközöket is futtatta, a hitelesítési adatok érvényességének ellenőrzése nélkül.
| A kutatók tesztjének eredménye | Érintett helyi beállításfájlok száma |
|---|---|
| Az Apiiro szerint hitelesítési adatot tartalmazott | 1122 |
| A Gitleaks jelzett rá | 564 |
| A TruffleHog jelzett rá | 643 |
| Egyik eszköz sem jelzett rá | 215 |
A két eszköz találati halmaza átfed, ezért a találatszámok nem adhatók egyszerűen össze. Az eredmények a kutatók konkrét tesztjére vonatkoznak, nem minden verzió és konfiguráció általános minősítésére. Az Apiiro szkennelési eredményei
A védekezési probléma a lefedettség. Egy jellegzetes szolgáltatói kulcsformátumokra hangolt keresőnek további felismerési szabályokra lehet szüksége a parancsargumentumokba, kapcsolati karakterláncokba vagy hitelesítési fejlécekbe írt értékek azonosításához.
A GitHub dokumentációja több, egymást kiegészítő megközelítést ír le: szolgáltatóspecifikus felismerést, általános és egyedi mintákat, valamint strukturálatlan titkos adatokhoz használható AI-alapú felismerést. A titokkeresés a kódtár teljes Git-történetére és valamennyi ágára is kiterjedhet. A GitHub titokkeresési dokumentációja
A biztonsági csapatoknak saját munkafolyamataikat tükröző, mesterséges tesztadatokkal érdemes ellenőrizniük a védelmet. A lényegi kérdés például az, hogy egy mentett parancsengedélybe írt tesztjelszót felismer-e a rendszer.
A negatív szkennelési eredmény hasznos információ, de nem teljes bizonyíték az érzékeny adatok hiányára.
A problémát korábban is jelezték
Az Anthropic Claude Code-kódtárában 2025. augusztus 11-én nyitott hibajelentés már leírta, hogy a jóváhagyott Bash-parancsokban szereplő hitelesítési adatok változatlanul, olvasható szövegként kerülnek a settings.local.json fájlba.
A bejelentés felvetette a véletlen verziókezelési közzététel és a tartós, titkosítatlan tárolás kockázatát. A hibajegyet 2026. január 3-án egy automatikus folyamat lezárta inaktivitás miatt; a GitHub „not planned” állapotot mutat. A lezárási üzenet nem igazolja, hogy a működést kijavították vagy érdemi biztonsági felülvizsgálat zárult le. A korábbi Claude Code-hibajelentés
Az Apiiro november 8-i frissítése már gyártói reakciót is tartalmaz. A beszámoló szerint Boris Cherny, a Claude Code vezetője jelezte, hogy az Anthropic megelőzési lehetőségeket vizsgál, köztük alapvető titokkeresés prototípusának elkészítését. Ez vizsgált fejlesztési irányt jelent, nem igazoltan kiadott javítást. Az Apiiro által közölt gyártói válasz
Miért nem elég törölni a fájlt?
Ha egy hitelesítési adat nyilvánosságra került, az aktuális fájlból való eltávolítása nem teszi újra bizalmassá.
A GitHub útmutatója első lépésként az érintett jelszó, token vagy kulcs visszavonását, illetve cseréjét írja elő. Korábbi commitok, elágaztatott kódtárak, helyi másolatok és más hivatkozások akkor is megőrizhetik az adatot, amikor az a legfrissebb fájlból már eltűnt.
A verziótörténet átírása külön tisztítási művelet. Egyeztetést igényel, megváltoztatja a commitazonosítókat, és megzavarhatja a folyamatban lévő munkát. A régi helyi másolatokból a törölt történet később vissza is kerülhet. A GitHub útmutatója érzékeny adatok eltávolításához
Az érintett szervezetnek három külön kérdésre kell választ adnia:
- Korlátozás: visszavonták vagy lecserélték-e a nyilvánosságra került hitelesítési adatot?
- Vizsgálat: történt-e váratlan vagy jogosulatlan használat a kitettség ideje alatt?
- Megelőzés: milyen folyamat engedte be az érzékeny adatot a közzétett kódtárba?
A fájl törlése önmagában egyik kérdést sem rendezi teljesen.
A vizsgálat során meg kell őrizni a releváns időpontokat, és át kell tekinteni az elérhető hitelesítési, adatbázis-, felhő- és csomagközzétételi naplókat. A szokatlan hozzáférések, jogosultságmódosítások vagy új hitelesítési adatok létrehozása szélesebb incidenskezelést indokolhat.
A megelőzésnek a közzététel előtt is működnie kell
A kódtárak védelmének a már elmentett adatok felismerése mellett a publikálás megakadályozását is támogatnia kell.
A GitHub push protection funkciója blokkolhatja a támogatott titkos adattípusokat tartalmazó feltöltéseket. A lefedettség az engedélyezett funkcióktól és mintáktól függ, ezért ellenőrizni kell, hogy a védelem a szervezet által ténylegesen használt hitelesítési adatokat is felismeri-e. A GitHub push protection dokumentációja
A fejlesztői felülvizsgálatnak az ügynökök konfigurációs változásaira is ki kell terjednie. Különösen fontosak a megosztott beállításfájlok: ezek közzététele lehet szándékos és indokolt, miközben egy belekerült jelszó publikálása nem az.
A mentett engedélyeket is rendszeresen át kell tekinteni. A Claude Code dokumentálja a pontos parancsokra és helyettesítő karakteres mintákra épülő szabályokat, valamint a /permissions felületet azok kezelésére. A Claude Code engedélyeinek kezelése
Egy szűken meghatározott, titkos adatot nem tartalmazó engedély csökkentheti a felesleges adatmegőrzést. A végrehajtási jogosultságok túlzott kiszélesítése azonban más kockázatot teremthet, ezért nem megfelelő csere egy jelszót tartalmazó szabály kiváltására.
A tartósabb megoldás a hitelesítés módjának áttervezése: a fejlesztői folyamat csak a szükséges adathoz és jogosultsághoz férjen hozzá, a szükséges ideig. A titkos érték lehetőleg ne kerüljön szó szerint a mentett parancsba, a munkanaplóba vagy a projektjegyzetbe.
Az AI-fejlesztőeszközök segédfájljai is biztonsági ellenőrzést igényelnek
Az OWASP titokkezelési útmutatója központi kezelést, részletes hozzáférési szabályokat, automatizálást, naplózást és a hitelesítési adatok teljes életciklusának kezelését javasolja. Ezek az elvek akkor is érvényesek, amikor AI-asszisztens vesz részt a fejlesztésben. Az OWASP titokkezelési útmutatója
A biztonsági vezetőknek ezért a generált alkalmazáskód mellett azt is vizsgálniuk kell, hogy a fejlesztői asszisztens milyen működési adatokat őriz meg, hol tárolja őket, meddig maradnak meg, és mely fájlok hagyhatják el a munkaállomást.
Hasznos elfogadási feltétel lehet, hogy az érzékeny értékek ne kerüljenek tartós jóváhagyásokba, a személyes konfiguráció a csapat szokásos munkafolyamataiban is kívül maradjon a verziókezelésen, és a közzétételi védelem reprezentatív tesztekkel igazoltan felismerje a jellemző hibákat.
Az azonnali feladat a nyilvánosságra került hitelesítési adatok azonosítása és érvénytelenítése. A hosszabb távú cél annak biztosítása, hogy az asszisztens munkájának nyilvántartása ne váljon éles rendszerekhez hozzáférést biztosító, felügyelet nélkül gyarapodó adattárrá.
Eredeti cím: Claude Code’s “Don’t Ask Again” Feature Linked To Public Exposure of Developer Credentials
