Andrii Horobchenko’s Post

𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗚𝗶𝘁𝗛𝘂𝗯 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝘀𝗵𝗼𝘂𝗹𝗱𝗻’𝘁 𝗯𝗲 𝘁𝗵𝗶𝘀 𝗽𝗮𝗶𝗻𝗳𝘂𝗹… 𝗯𝘂𝘁 𝗶𝘁 𝗶𝘀. Over the past few months, I kept running into a frustrating issue: using work + personal GitHub accounts on the same machine without breaking SSH or mixing identities. So I built a clean, repeatable SSH setup that solves the following: • Authentication conflicts • Wrong-account commits • Broken push/pull workflows What’s inside the guide: • Separate SSH keys per account • Smart aliasing via ~/.ssh/config • Per-repo Git identity setup • Quick debugging checks The goal was simple: 👉 Make it predictable and production-safe—not just “works on my machine." If you’ve ever pushed code from the wrong account… you know the pain. 😅 🔗 GitHub repo: https://lnkd.in/dFH75WvV If this helps, consider giving the repo a ⭐ #github #git #ssh #developers #webdev #softwareengineering #opensource

A question I keep turning over: How many developers actually understand Git — versus just knowing enough commands to survive? I've been writing a comprehensive GitHub Handbook (beginner-friendly, two volumes, covers everything from "what is a repository" to the AI agents now opening pull requests autonomously) and the experience has been clarifying. Most of us learned GitHub by osmosis. A teammate showed us `git push`. We got yelled at for force-pushing once. We figured out pull requests. We never quite learned why any of it works the way it does. That's fine — until something breaks. And in 2026 the stakes are higher than ever, because the tools around Git have exploded. Copilot agents write code. Autofix patches vulnerabilities. MCP servers connect agents to your whole stack. The people who thrive in this environment are the ones with solid fundamentals + willingness to learn the new surface area. So my handbook starts from zero and ends at the current frontier. Volume I is the foundation. Volume II covers advanced topics and the comprehensive AI future. If that sounds useful — comment below and I'll send it your way. Curious to hear: what's the one GitHub concept you wish someone had explained to you earlier? #GitHub #Git #SoftwareDevelopment #AI #GitHubCopilot #LearningInPublic

Ever seen a commit on GitHub attributed to an account that can't even push to the repo? I thought it was a bug. It's not. Let me explain- Spent an hour chasing a git ghost today. 🦞 Pushed commits from my personal GitHub account to a private repo I own. Every commit kept showing up attributed to a different account of mine - one I'd already removed as a collaborator. First instinct: credential leakage. Wrong SSH key. Stale gh token. Something. None of it. The resolution turned out to be a reminder of how git identity actually works. "Committed by X" on a GitHub commit page does NOT mean "X pushed this commit." Git's author / committer / pusher distinction is intentional , it is designed for maintainer workflows where one person applies a patch authored by someone else. Every git push involves three independent identity systems: • SSH key or HTTPS token → who pushed • git config user.email → whose face shows on the commit • gh auth status → who API calls run as Fix the right layer. Sometimes the answer isn't in auth at all. #git #github #devtools #softwareengineering

𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹 𝗚𝗶𝘁𝗛𝘂𝗯 𝗩𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆 (𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟯𝟴𝟱𝟰) – 𝗔 𝗟𝗲𝘀𝘀𝗼𝗻 𝗶𝗻 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 A recent discovery by Wiz revealed a Remote Code Execution (RCE) flaw in GitHub’s internal Git infrastructure. What stands out is how simple the trigger was a single git push from an authenticated user. 𝗪𝗵𝗮𝘁 𝘄𝗲𝗻𝘁 𝘄𝗿𝗼𝗻𝗴? Internal services trusted a shared header (X-Stat) without proper validation User-controlled input (git push options) was not sanitized A delimiter-based parsing design allowed field injection Multiple components made reasonable assumptions but together, they created a critical vulnerability 𝗜𝗺𝗽𝗮𝗰𝘁 𝘖𝘯 𝘎𝘪𝘵𝘏𝘶𝘣 𝘌𝘯𝘵𝘦𝘳𝘱𝘳𝘪𝘴𝘦 𝘚𝘦𝘳𝘷𝘦𝘳: 𝘧𝘶𝘭𝘭 𝘴𝘦𝘳𝘷𝘦𝘳 𝘤𝘰𝘮𝘱𝘳𝘰𝘮𝘪𝘴𝘦 𝘖𝘯 𝘎𝘪𝘵𝘏𝘶𝘣.𝘤𝘰𝘮: 𝘳𝘪𝘴𝘬 𝘰𝘧 𝘤𝘳𝘰𝘴𝘴-𝘵𝘦𝘯𝘢𝘯𝘵 𝘦𝘹𝘱𝘰𝘴𝘶𝘳𝘦 𝘥𝘶𝘦 𝘵𝘰 𝘴𝘩𝘢𝘳𝘦𝘥 𝘪𝘯𝘧𝘳𝘢𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝘁𝗲𝗮𝗰𝗵𝗲𝘀 𝘂𝘀 This is less about one bug and more about how systems are built:  • Never blindly trust internal protocols  • Do not rely on upstream services for sanitization  • Be careful with delimiter-based parsing formats  • Validate data at every boundary, even inside your system Another important shift: this vulnerability was discovered using AI-assisted reverse engineering.  That changes how we should think about both offense and defense in security. 𝗔𝗰𝘁𝗶𝗼𝗻 GitHub has already been patched. GitHub Enterprise Server users should upgrade to version 3.19.3 or later. 𝘛𝘩𝘦 𝘣𝘪𝘨𝘨𝘦𝘳 𝘵𝘢𝘬𝘦𝘢𝘸𝘢𝘺 𝘪𝘴 𝘴𝘪𝘮𝘱𝘭𝘦: 𝘴𝘺𝘴𝘵𝘦𝘮𝘴 𝘳𝘢𝘳𝘦𝘭𝘺 𝘧𝘢𝘪𝘭 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘰𝘧 𝘰𝘯𝘦 𝘮𝘪𝘴𝘵𝘢𝘬𝘦. 𝘛𝘩𝘦𝘺 𝘧𝘢𝘪𝘭 𝘸𝘩𝘦𝘯 𝘴𝘮𝘢𝘭𝘭 𝘢𝘴𝘴𝘶𝘮𝘱𝘵𝘪𝘰𝘯𝘴 𝘭𝘪𝘯𝘦 𝘶𝘱 𝘪𝘯 𝘵𝘩𝘦 𝘸𝘳𝘰𝘯𝘨 𝘸𝘢𝘺. #CyberSecurity #GitHub #SystemDesign #DevSecOps #CloudSecurity

🚨 𝗚𝗶𝘁𝗛𝘂𝗯 𝗵𝗮𝗱 𝗮 𝗿𝗲𝗺𝗼𝘁𝗲 𝗰𝗼𝗱𝗲 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗯𝘂𝗴. One git push was enough. CVE-2026-3854, disclosed today by Wiz Research. CVSS 8.7. A push option injection in GitHub's internal Git proxy let an authenticated user execute arbitrary code on backend infrastructure — and reach across tenants into millions of other organizations' repositories on the same shared storage node. The root cause is almost embarrassing: GitHub's internal babeld proxy embeds git push -o values into a semicolon-delimited header without sanitizing the semicolon. That one missing escape opened the door to header injection → command injection → RCE. The chain is three injections in a single push: 𝗿𝗮𝗶𝗹𝘀_𝗲𝗻𝘃 → bypass the Rails sandbox 𝗰𝘂𝘀𝘁𝗼𝗺_𝗵𝗼𝗼𝗸𝘀_𝗱𝗶𝗿 → redirect Git hooks to attacker-controlled content 𝗿𝗲𝗽𝗼_𝗽𝗿𝗲_𝗿𝗲𝗰𝗲𝗶𝘃𝗲_𝗵𝗼𝗼𝗸𝘀 with path traversal → arbitrary commands as the git user No malware drop. No social engineering. One command. GitHub.com is already patched. GitHub Enterprise Server is the problem — ~88% of instances were still vulnerable at disclosure. Check your GHES version: 𝘤𝘶𝘳𝘭 -𝘬 𝘩𝘵𝘵𝘱𝘴://𝘺𝘰𝘶𝘳-𝘪𝘯𝘴𝘵𝘢𝘯𝘤𝘦/𝘢𝘱𝘪/𝘷3/𝘮𝘦𝘵𝘢 | 𝘫𝘲 .𝘪𝘯𝘴𝘵𝘢𝘭𝘭𝘦𝘥_𝘷𝘦𝘳𝘴𝘪𝘰𝘯 Below 3.19.3? 𝗣𝗮𝘁𝗰𝗵 𝘁𝗼𝗱𝗮𝘆.

GitHub found sensitive info in 11% of public repos. 60% of developers admitted to hardcoding API keys. The breaches that followed weren't anomalies. Secret sprawl is a governance problem, not a developer-hygiene problem. Finding exposed credentials is step one. Proving they're actually closed is where most programs stall. What's your process for continuously validating that revoked keys stay revoked? #CTEM #AppSec

I spent years thinking the problem was getting my detections into GitHub. So I set up repos, built CI/CD pipelines, fought with YAML configs, and spent more weekends debugging pipelines than actually writing detections. And after all that work I still couldn't answer the one question that mattered: are our detections actually working? Wrote about what I got wrong as a detection engineer and what I think the community is getting wrong about detection as code. GitHub isn't the goal, it never was. Link in the comments.

🚨 It's been a rough week for GitHub. Here's your 60-second debrief: ───────────────────────── 🔴 CVE-2026-3854 — The scariest one ───────────────────────── One git push. That's all it took. Wiz Research discovered a critical RCE vulnerability in GitHub's internal git infrastructure — any authenticated user could execute arbitrary commands on backend servers using nothing but a standard git client. GitHub.com: patched within 6 hours of disclosure. ✅ GHES: patch available (3.19.3+) — but 88% of instances are still vulnerable. ❌ If you run GitHub Enterprise Server, stop reading and go patch. ───────────────────────── 🟡 April 27 — The cascade ───────────────────────── Searches failing. Workflows not running. Projects not loading. A broad infrastructure issue hit GitHub yesterday, impacting Actions, search, and project views across the platform. RCA still pending. ───────────────────────── 🟠 April 23 — The silent one ───────────────────────── This one deserves more attention than it got. A regression in the merge queue caused PRs using squash or rebase to be merged with *incorrect contents* — silently, for 4.5 hours. No build failures. No red flags. Just wrong code in your main branch. GitHub has since rolled back the fix and is expanding test coverage, but it's a reminder: correctness bugs are scarier than availability bugs. ───────────────────────── Three different failure modes in one week: 🔐 A security flaw hiding in plain sight 🔀 A correctness bug disguised as normal operation  📉 A classic availability degradation 🗒️ A few takeaways: → Patch your GHES instances — CVE-2026-3854 is critical 🔴 → If you used merge queue on April 23 between 16:05–20:43 UTC, audit your merges 🟡 → Availability is visible. Correctness bugs aren't. Build for both. 🟠 Platform reliability isn't one problem. It's all three, simultaneously. 😨 The most dangerous incidents aren't the ones that take your system down — they're the ones that let it keep running, broken, while everyone assumes it's fine. Stay paranoid. Stay patched ⛑️ 🔗 Look for detailed report in comments! #GitHub #DevOps #PlatformEngineering #GitHubEnterprise #Security #SRE

The most productive engineer on GitHub last week got permanently banned. His crime? He used an AI agent that actually worked. A Korean CTO built a 13-step agent harness. Pointed it at 100+ major open-source repos. In 72 hours: 500+ commits. 130+ pull requests. Some merged by Kubernetes maintainers. Some merged by Hugging Face. Then GitHub banned his account for spam. Read that again. The PRs were good enough for Kubernetes to merge. But GitHub's abuse detection flagged the entire account. The platform that hosts your agents cannot tell the difference between a 10x engineer and a spammer. And it chose spammer. This isn't a one-off glitch. This is the infrastructure layer sending a message: we aren't built for agentic workflows yet. Your coding agent's biggest bottleneck isn't the model. It's whether the platform will let you use it.

Github's classification of the AI agent's rapid rate of commits as spam is correct. "Flooding", "exhausting API resource limits", there are other names for it too. It's a safeguard against malicious automation. I'm not sure people understand how insane the spam is going to get with agentic AI. For the time being, it's smart to have these kind of safeguards against automated actions we can't really control or predict.