LangChain CVE-2025-68664: Paano Tumatawid ang PII sa Iyong RAG Pipeline
Na-update para sa 2026.
Isang kritikal na depekto ang natuklasan sa LangChain noong huling bahagi ng 2025. Ang CVE ay CVE-2025-68664. Ang CVSS score ay 9.3 (Kritikal).
Tina-target nito ang serialization code ng LangChain.
Ano ang Ginagawa ng CVE-2025-68664
Ang LangChain ay may dalawang serialization function: dumps() at dumpd(). Kino-convert nila ang mga Python object sa teksto.
Ang depekto ay nasa paghawak ng closure.
Kapag nag-serialize ang LangChain ng isang callable, kinukuha nito ang closure context.
Ang isang attacker na kumokontrol sa tugon ng LLM ay maaaring mag-trigger ng dumps(). Pagkatapos ay binabasa ng function ang mga environment variable mula sa Python process.
Ang resulta ay paglalantad ng datos. Maaaring lumabas ang mga API key, database string, JWT secret, at AWS credential sa output ng modelo.
Ang isang attacker na nag-inject ng teksto sa isang RAG source document ay maaaring basahin ang iyong mga production secret.
Mga apektadong bersyon: Ang LangChain na mas mababa sa 0.3.22 (Python). Ang bersyon 0.3.22 ay may pag-aayos.
Ipinakita ng datos ng PyPI ang malawak na paggamit ng mga mas lumang bersyon hanggang Marso 2026.
Paano Tumatawid ang PII sa mga RAG Pipeline
Ang CVE-2025-68664 ay dramatiko. Ngunit ito ay isang kaso lamang ng mas malawak na problema.
Nagtatagas ang datos sa pamamagitan ng mga RAG pipeline nang regular. Hindi kailangan ng attacker.
Narito ang isang karaniwang enterprise RAG setup.
Una, ingestion. Ini-index mo ang mga dokumento ng kumpanya sa isang vector store. Isipin ang mga support ticket, email ng customer, kontrata, at rekord ng HR.
Ang mga karaniwang vector store ay Pinecone, Weaviate, at pgvector.
Susunod, retrieval. Nagtatanong ang isang gumagamit. Kinukuha ng sistema ang limang pinaka-kaugnay na chunk mula sa store.
Pagkatapos, generation. Ang mga chunk na iyon ay napupunta sa isang LLM — GPT-4o, Claude, o Gemini — bilang konteksto.
Ang ikalawang hakbang ang problema. Ang mga nakuhang chunk ay nagtataglay ng anumang nilalaman ng mga source document. Kasama dito ang:
- Mga pangalan ng customer, email address, at numero ng telepono
- Mga halaga ng kontrata, numero ng account, at mga tax identifier
- Datos ng sahod ng empleyado at mga tala ng performance review
- Mga pangalan ng pasyente sa mga klinikal na tala
- Mga national ID number sa mga file ng imigrasyon
Napupunta ang datos na iyon sa LLM nang buo. Maaari itong lumabas sa output ng modelo.
Nai-log ito ng LLM provider. Nakaupo ito sa iyong kasaysayan ng pag-uusap. Dumadaloy ito sa iyong observability stack.
Hindi kailangan ng pag-atake. Ganito gumagana ang RAG ayon sa disenyo. Ang disenyo ay lumilikha ng tunay na panganib sa privacy.
68 Pattern ng Secret sa Mga Enterprise Document Store
Sinusubaybayan ng mga security tool ang 68 kilalang pattern ng secret. Mas madalas itong lumabas kaysa sa inaasahan ng mga koponan.
Narito ang mga pinakakaraniwan.
- Mga AWS Access Key ID (
AKIA...) - Mga OpenAI API key (
sk-...) - Mga Anthropic API key (
sk-ant-...) - Mga URI ng database (
postgresql://user:password@host/db) - Mga JWT token (base64-encoded na header)
- Mga GitHub Personal Access Token
- Mga Stripe secret key (
sk_live_...) - Mga SendGrid API key
- Mga Twilio account SID at auth token
- Mga private key PEM block
Maaaring may hawak na API key ng customer ang isang support ticket mula sa isang debug session.
Maaaring may kasamang database credential ang isang kontrata mula sa isang teknikal na handoff.
Ang isang config file na na-index nang hindi sinasadya ay maaaring maglantad ng isang buong secrets store.
Kapag ang mga file na ito ay pumapasok sa isang vector store nang walang sanitization, ang bawat query ay maaaring maipasa ang mga secret sa LLM.
Maaari rin silang umabot sa end user.
Ayusin Ito: Mag-Anonymize Bago Mag-Embed
Ang tamang pamamaraan ay nag-a-anonymize ng mga dokumento bago ang chunking at embedding.
Kinakailangan ang hakbang na ito para sa anumang sistema na humahawak ng datos ng customer.
Narito ang isang halimbawa sa Python gamit ang anonym.legal API:
import requests
import os
ANONYM_API_KEY = os.environ["ANONYM_API_KEY"]
ANONYM_BASE_URL = "https://anonym.legal/api"
def anonymize_before_embedding(text: str) -> tuple[str, dict]:
"""Mag-anonymize ng PII bago mag-embed."""
response = requests.post(
f"{ANONYM_BASE_URL}/presidio/anonymize",
json={
"text": text,
"language": "en",
"anonymizers": {
"DEFAULT": {"type": "replace", "new_value": "[REDACTED]"},
"PERSON": {"type": "mask", "masking_char": "*", "chars_to_mask": 4, "from_end": False},
"EMAIL_ADDRESS": {"type": "replace", "new_value": "[EMAIL]"},
"PHONE_NUMBER": {"type": "replace", "new_value": "[PHONE]"},
"CRYPTO": {"type": "replace", "new_value": "[SECRET]"},
"URL": {"type": "keep"},
}
},
headers={"Authorization": f"Bearer {ANONYM_API_KEY}"}
)
result = response.json()
return result["text"], result.get("items", [])
def build_rag_index(documents: list[str], vectorstore):
"""Bumuo ng RAG index na may malinis na dokumento lamang."""
anonymized_docs = []
for doc in documents:
clean_text, entities = anonymize_before_embedding(doc)
anonymized_docs.append(clean_text)
print(f"Nag-alis ng {len(entities)} PII entity mula sa dokumento")
vectorstore.add_texts(anonymized_docs)
Sinasaklaw ng anonym.legal API ang 285+ na uri ng entity. Nahahuli ang mga pangalan, email, numero ng telepono, national ID, API key, at URI ng database.
Walang sensitibong bagay ang umabot sa vector store. Kaya walang sensitibong bagay ang maaaring tumawid sa mga gumagamit.
Tingnan ang gabay ng developer para sa mga pattern ng setup ng LangChain at LlamaIndex.
Ayusin ang CVE-2025-68664 Ngayon Din
Kung nagpapatakbo ka ng LangChain na mas mababa sa 0.3.22, mag-update ngayon:
pip install "langchain>=0.3.22" "langchain-core>=0.3.22"
Pagkatapos ng pag-patch, suriin ang iyong mga chain config para sa panganib ng injection. Narito ang tatlong hakbang na dapat gawin.
Una, i-validate ang mga nakuhang chunk. Gawin ito bago sila umabot sa LLM.
Alisin ang nilalaman na tumutugma sa mga pattern ng injection tulad ng ignore previous instructions, system:, o <INST>.
Pangalawa, mag-anonymize bago mag-embed. Pinaliit nito ang attack surface.
Kung maganap ang injection, ang sensitibong datos ay wala na roon upang makuha.
Pangatlo, paghigpiting ang mga pahintulot ng chain. Ang mga LangChain chain ay hindi dapat nagbabasa ng mga environment variable na lampas sa kailangan nila.
Gumamit ng service account na may minimal na scope.
Ang Matematika ay Simple
Ang CVSS score ay 9.3. Ang pag-aayos ay isang API call bawat dokumento.
Ang kumbinasyon ng CVE-2025-68664 at pangkalahatang panganib sa datos ng RAG ay isang tunay na pananagutan.
Malinaw ang solusyon: mag-anonymize sa ingestion, hindi sa oras ng query.
Suriin ang pangkalahatang-ideya ng seguridad at pagsunod para sa mga kinakailangan ng enterprise RAG.
Mga Pinagkukunan
- NVD CVE-2025-68664, CVSS 9.3, kahinaan ng serialization ng LangChain
- LangChain security advisory, langchain-ai/langchain GitHub, 2025
- OWASP LLM Top 10: LLM01 Prompt Injection, LLM06 Sensitive Information Disclosure
- anonym.legal entity type documentation — 285+ na sinusuportahang uri ng entity