Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

CVE-2026-19478 is a code injection vulnerability in GitLab Community Edition and Enterprise Edition, caused by improper handling of a GraphQL directive in the application’s API layer. GitLab disclosed the issue and shipped fixes in an ad hoc critical patch release on August 17, 2026, outside its normal twice-monthly security schedule. The vulnerability carries a CVSS base score of 9.4 (Critical) as assigned by GitLab. Exploitation requires no authentication and no user interaction.

An unauthenticated SQL injection vulnerability exists in the jsonArrayContains filter function in GeoTools, the geospatial library that underpins GeoServer. When an OGC filter is evaluated against a PostGIS data store, the value passed to jsonArrayContains is written into the generated SQL statement without escaping, allowing an attacker to alter the query the database executes.

Researchers at Microsoft warn that phishing emails are still the top initial access vector, with more than 2 billion phishing threats detected each month during the second quarter of 2026.

Every fall, school districts and universities across the country race to onboard thousands of new students, faculty and staff, provisioning accounts, issuing credentials and connecting a wave of new devices to institutional networks. It is a moment of organized chaos, and cybercriminals know it.

In late July 2026, over 30 municipal water systems across Minnesota were targeted in coordinated cyber attacks that disrupted the Operational Technology (OT) used to remotely monitor and control water equipment. The attacks initially unfolded on July 26 and 27, striking multiple automated control systems across the state, including those in Plymouth, Braham and South St. Paul.

The most popular advice about GLBA security requirements is also the least useful: review the policy annually, collect signatures, and keep the evidence in an audit folder. That approach may prove that someone approved a program. It doesn't prove that multifactor authentication protects every relevant system, that logs capture unauthorized access, or that the incident response team can identify a reportable event quickly enough to act.

Your source code sits on GitHub, GitLab, Bitbucket, or Azure DevOps, along with your pipeline configurations, issue history, permissions, and metadata. Most teams assume it’s safe there because it works. But is it? Financial institutions, technology companies, and software houses all build the systems they run on. Code stopped being a byproduct of the business and became the business. And as it turns out, it needs protection of its own.

Enterprises settled the question:“is my software actually working” about a decade ago. Not by hiring more people to read logs, but by instrumenting the data plane once and letting anyone query it. Observability became infrastructure, and the people who used to read logs went and solved harder problems. GRC has never had that moment. We still read the logs, opine, and complete the attestation. And then it stops. The demo proved the concept and became the ceiling.

Have you ever tried to answer “Is this container safe to run?” If yes, then you know how tricky that question is. Securing containers is one of the toughest jobs in security, and hunting vulnerabilities across an estate of them gives security folks the same vibe as hunting in the fifth domain. Container vulnerabilities can live almost anywhere, from the image layers down to the kernel, and every week, a new base image, a new dependency, or a new manifest change opens a fresh gap.

Most engineering teams believe they solved secret scanning the day they flipped on GitHub’s default toggle, but the game doesn’t stop there. In many cases, an overlooked leak can spiral into a severe data breach, especially when an LLM is connected to sensitive data, internal APIs, or production infrastructure. Exposed credentials are hot and always in demand, and there’s plenty left online for bad actors to hunt.