Git Security | Breaking Cybersecurity News | The Hacker News

New research shows that a signed Git commit's hash is not the one-of-a-kind name that much of the software world assumes it to be. Given any signed commit, someone without the signing key can mint a second commit with the same files, author, and date, and a valid signature, GitHub still stamps "Verified." Everything a reviewer would check matches. The commit's hash does not. That matters because so many systems treat a verified commit hash as a permanent, unique name for its contents. Here is the concrete failure: block a bad commit by its hash, and an attacker can re-push the same content under a fresh, still-"Verified" hash your blocklist has never seen. Deduplication, provenance logs, and reproducible-build records that key on the hash inherit the same soft spot. A compromised or hostile mirror can hand cloners validly signed commits whose hashes differ from those on the canonical forge. What this is not is a way to slip different code past a sig...

The (Other) Risk in Finance A few years ago, a Washington-based real estate developer received a document link from First American – a financial services company in the real estate industry – relating to a deal he was working on. Everything about the document was perfectly fine and normal. The odd part, he  told  a reporter, was that if he changed a single digit in the URL, suddenly, he could see somebody else's document. Change it again, a different document. With no technical tools or expertise, the developer could retrieve FirstAm records dating back to 2003 – 885  million  in total, many containing the kinds of sensitive data disclosed in real estate dealings, like bank details, social security numbers, and of course, names and addresses. That nearly a billion records could leak from so simple a web vulnerability seemed shocking. Yet even more severe consequences befall financial services companies every week. Verizon, in its most recent  Data Breach Inv...