Git
6 articles with this tag
GitLab CVE-2026-110264 (CVSS 10.0) and the exploited CVE-2026-97229: how to check and update a self-managed GitLab
On October 21, 2026, GitLab released critical patch versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for Community Edition (CE) and Enterprise Edition (EE). The most severe flaw, CVE-2026-110264 (CVSS 10.0), is an integer overflow when compiling a specially crafted regular expression that, under certain conditions, could allow an unauthenticated user to execute arbitrary code on the GitLab server. Almost every version from 7.0 onward is affected. On October 29, CISA added a sister flaw, CVE-2026-97229 (CVSS 10.0, CWE-190), to its Known Exploited Vulnerabilities (KEV) catalog with a due date of November 1. It is the same kind of bug (an integer overflow in the CI/CD regular expression compiler, reachable by an unauthenticated user), GitLab fixed it earlier on October 12 in 19.4.2, 19.3.5 and 19.2.8, and it affects only 19.2.0 to 19.2.7, 19.3.0 to 19.3.4 and 19.4.0 to 19.4.1. Anyone still below 19.4.2, 19.3.5 or 19.2.8 is exposed to an exploited flaw. Upgrading to the versions recommended here (19.5.1, 19.4.3, 19.3.6, 19.2.9) also fixes CVE-2026-97229. GitLab.com is already patched; self-managed installations need to upgrade. The same October 21 release fixes two High-severity flaws (CVSS 8.2 and 7.5) and others, but those fixes ship only in the 19.3.6, 19.4.3 and 19.5.1 lines. The root cause is in Ruby's regular expression engine (Onigmo), and Ruby released 4.0.9, 3.4.12 and 3.3.13 on October 23. Applications that compile a regexp from attacker-controlled strings are affected, and Regexp.timeout does not protect against the bugs. GitLab's notices do not say CVE-2026-110264 has been exploited, and it is not in KEV as of October 30. Alpine Linux reported on its own GitLab an attempted attack through CVE-2026-97229 on October 20 and 21, and that upgrading GitLab alone (to 19.3.6) did not close the flaw because the fix also needed a patched Ruby; it rebuilt the instance and found no evidence that attacker code ran. This site's conclusion: upgrade self-managed GitLab today after checking the required upgrade stops, end up on 19.3.6 or later, and if you build GitLab yourself or run your own Ruby, check that Ruby is 3.3.13, 3.4.12 or 4.0.9 or later too. Ruby applications should move to a fixed Ruby and stop building regexps from user input.
Setting up GitHub two-factor authentication (2FA): authenticator app, passkeys, recovery codes, and what to do if you lose your phone
A guide to setting up two-factor authentication (2FA) on GitHub and avoiding lockout. Since March 2023, GitHub has been requiring 2FA, group by group, for users who contribute code on GitHub.com; once selected, you get a 45-day enrollment period and a 7-day grace period, after which you cannot use GitHub.com until 2FA is on. GitHub Docs recommends a TOTP authenticator app as the primary method with a passkey or security key as backup (passkeys, security keys and GitHub Mobile can only be added after TOTP or SMS is set up). This site's take: the common 2FA failure on GitHub is not account takeover but locking yourself out, and GitHub Support cannot restore an account whose 2FA credentials and recovery methods are all lost. Save the 16 recovery codes in a password manager and register a second method on the same day. While you are there, move to expiring fine-grained tokens, prune authorized apps and SSH keys, and check push protection and Dependabot alerts.
543,699 credentials published on GitHub still worked (2026 study): why you must revoke, not delete, and what developers should do
A security company that sells secret-scanning tools examined a snapshot of about 224 million public repositories collected for LLM training and reported that 543,699 credentials still authenticated in late July 2026. The median time since exposure was 784 days. Almost all npm and GitHub tokens had been invalidated, while 75-88% of database connection strings still worked. More than 199,000 of the live credentials appeared after GitHub turned push protection on by default, and over half of the live ones were types push protection does not block by default. This site's conclusion: a credential pushed to a public repository cannot be recalled by deleting the file or rewriting history, so revoke it first. Whether a leaked credential is revoked automatically depends on the issuer; connection strings and many API keys stay valid until you stop them.
CAMPFIRE Unauthorized Access: 225,846 Unique User Records at Risk — Actions for Users and Developers
According to CAMPFIRE, a GitHub credential issued by an employee was misused by a third party; information visible on GitHub was then used to obtain credentials for a cloud environment the company uses for internal business operations, and part of its management area was accessed. Names, addresses, phone numbers, email addresses and bank account details in 225,846 unique affected-user records (project owners, supporters, partners) may have leaked; credit card data was not involved. The service platform runs in a separate environment and no misuse or tampering was found there. Users should watch for messages about refunds or payout account confirmation and check bank statements. Developers and operators get two lessons. Customer data also lives in internal business environments even when production is well protected. And work tokens can end up on machines the company doesn't manage, so organization settings must limit how long a token stays valid and what it can access.
Stop secrets before they commit with gitleaks: catch API-key leaks before the push
Secrets can't be 'deleted after they leak.' Once committed, a secret stays in Git history, and once pushed it must be treated as leaked — the key needs revoking/rotating. gitleaks is a free tool that scans the whole repo and commit history with regex/entropy to find API keys, private keys, and tokens. The core of the defense is two checks: a pre-commit hook that stops it locally before the push, and CI/cron that catches what slips through. .gitignore only prevents new tracking — it can't detect, so you still need a scanner.
Self-hosted Git vs GitHub: which is actually more secure?
Self-hosting Git doesn't make you 'more secure' — it relocates the risk. The accidental-public-exposure class disappears, but patching the server, backups, and pre-commit secret detection move onto you. The right call if you keep doing that work; worse than GitHub if you neglect it. This site's view: self-hosting only works bundled with its compensating controls.