<![CDATA[Abhinav Yadav]]>https://yadui.hashnode.devRSS for NodeSat, 07 Nov 2026 12:56:11 GMT60<![CDATA[Always Set persist-credentials: false in actions/checkout]]>https://yadui.hashnode.dev/always-set-persist-credentials-false-in-actions-checkouthttps://yadui.hashnode.dev/always-set-persist-credentials-false-in-actions-checkoutFri, 30 Oct 2026 17:44:13 GMTThere's a default in `actions/checkout` that most teams never change — and that quietly leaves a GitHub token sitting in a readable file for every subsequent step in the job.

The fix is one line. The reasoning is worth understanding.

What the full guide covers

  • The Setting
  • What the File Looks Like
  • How Easy It Is to Exploit
  • The Practical Risk
  • What If I Need Git Auth in Later Steps?
  • Pinning Actions by Commit SHA
  • Automated Detection
  • Checklist

Read the complete guide, with commands and sources, on my site: Always Set persist-credentials: false in actions/checkout

Written by Abhinav Yadav, Cloud & AI Engineer. More at yadui.dev.

]]><![CDATA[Stop giving AI agents your production keys]]>https://yadui.hashnode.dev/stop-giving-ai-agents-your-production-keyshttps://yadui.hashnode.dev/stop-giving-ai-agents-your-production-keysFri, 30 Oct 2026 17:43:48 GMTOn 15 October 2026, CERT-In issued advisory CIAD-2026-0049, rated critical, titled "AI Agents as Attack Vectors". It describes two kinds of incident, and both come down to how AI agent credentials are exposed and scoped.

In the first, AI model providers voluntarily disclosed that their models, during research and evaluation on the internet, reached the live systems of Indian organizations. The advisory says the agents read business records, including personal data and confidential material, using credentials and connection settings exposed in application configuration and public code repositories, and through permissive cloud service roles. It states that the agents' actions exceeded their assigned tasks and that none of the affected organizations detected the access themselves.

What the full guide covers

  • What CERT-In reported
  • Two sides of the same problem
  • Step 1: find the keys you already leaked
  • Step 2: replace stored secrets with workload identity
  • Step 3: one identity per agent run, scoped to the task
  • Step 4: default-deny egress, enforced by the network
  • Step 5: logs the agent cannot edit
  • A short checklist

Read the complete guide, with commands and sources, on my site: Stop giving AI agents your production keys

Written by Abhinav Yadav, Cloud & AI Engineer. More at yadui.dev.

]]><![CDATA[PHP2Shell: a practical patch and check guide for PHP servers]]>https://yadui.hashnode.dev/php2shell-a-practical-patch-and-check-guide-for-php-servershttps://yadui.hashnode.dev/php2shell-a-practical-patch-and-check-guide-for-php-serversFri, 30 Oct 2026 17:43:23 GMTPHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619. On October 21, 2026, the PHP project shipped emergency releases, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to fix two critical flaws that it says "can allow unauthenticated remote code execution" (PHP security advisory). The day before, PHP had given advance notice that both were rated CVSS v4.0 9.2. If you upgrade, also rotate any secrets a compromised host could have read; the Railway breach the same week shows why.

Two days later, on October 23, PHP published a short informational advisory about a separate issue, CVE-2026-115560. It is not fixed by the October 21 releases. PHP calls it "an unlikely RCE vector" and is handling it in the regular release cycle rather than with another emergency release.

What the full guide covers

  • What happened
  • Who is exposed
  • What attackers are doing
  • The checklist
  • What comes next

Read the complete guide, with commands and sources, on my site: PHP2Shell: a practical patch and check guide for PHP servers

Written by Abhinav Yadav, Cloud & AI Engineer. More at yadui.dev.

]]><![CDATA[LiteLLM 1.107.0 compromise: incident response guide]]>https://yadui.hashnode.dev/litellm-1-107-0-compromise-incident-response-guidehttps://yadui.hashnode.dev/litellm-1-107-0-compromise-incident-response-guideFri, 30 Oct 2026 17:40:32 GMTThe LiteLLM 1.107.0 compromise began on October 21, 2026, when a compromised litellm==1.107.0 was published to PyPI and to LiteLLM's container registries. LiteLLM's incident post states that earlier versions are safe, that the affected releases were pulled, and that customers on the private enterprise release were not affected. Its attack-chain post says the artifacts were live for about two hours: PyPI releases were frozen by 13:23 UTC and Docker images removed by 14:20 UTC.

Two hours is enough. LiteLLM is commonly deployed as a gateway between applications and model providers, and Microsoft's analysis notes that in that position it may hold model-provider API keys, database connection strings, workload identities and routing configuration. The same package also sits on developer laptops and build agents. If you run an AI gateway, treat this as a template for the next incident, whichever package it is.

What the full guide covers

  • What happened
  • Why "I never imported it" is not a defence
  • What the collector went after
  • Response, in order
  • Hardening that would have narrowed the blast radius
  • The lesson upstream: one unrevoked key, one unscoped token

Read the complete guide, with commands and sources, on my site: LiteLLM 1.107.0 compromise: incident response guide

Written by Abhinav Yadav, Cloud & AI Engineer. More at yadui.dev.

]]>