API keys
4 articles with this tag
Unauthorized Access to the Studio Website Builder: All Users' Data and Form Submissions May Have Leaked — What Form Senders and Site Owners Should Do
On October 16, 2026, Studio Inc. announced that a third party had gained unauthorized access to the cloud environment it uses, and that data on every customer registered with its website builder Studio may have been leaked. The third party exploited a vulnerability in some Studio features to access the environment and made its data retrievable from outside. The confirmed period of unauthorized access is September 30 to October 1, 2026 (Japan time); the company found it in an internal investigation on October 13 and finished fixing the vulnerability and closing the route on October 13–14. Data that may have leaked includes account data (user names, email addresses, hashed passwords and more), design editor and CMS content, the contents of forms submitted on Studio-built sites, live preview URLs, API keys and tokens for external services registered in API integrations, passwords of password-protected pages, and webhook notification URLs. Some data stored encrypted may also have been read, because the key needed to decrypt it was read in the same access. The company has not confirmed that a third party actually took the data, but is treating it as taken. The number of people affected and whether any misuse has occurred are under investigation. Companies and organizations that built sites with Studio have also said that personal data sent through their forms may have leaked: Luup gave 21,368 records, Link-U Group 7,663, TRUSTART about 1,440 and Saitama Prefecture's Saitama Green Forest Museum 162. On October 17, at the request of Japan's Personal Information Protection Commission (PPC), Studio Inc. asked form users to put their individual reports to the PPC on hold (notifying the affected individuals is not on hold). This site's conclusion: if you sent a form on a Studio-built site, check that site owner's notice and do not open links in messages that mention what you sent. Site owners should change their password and rotate integration keys in the order Studio Inc. gives.
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.
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.
Security basics: what's actually dangerous about .env and API keys
Start here. Understand what happens when .env and API keys leak (someone uses the service as you, and you get billed for it), then adopt four habits today: don't expose them, don't commit them, rotate everything if leaked, and self-check.