Security
Headlines
HeadlinesLatestCVEs

Tag

#git

Blind Eagle Linked to Russian Host Proton66 in Latin America Attacks

Blind Eagle hackers linked to Russian host Proton66 to target banks in Latin America using phishing and RATs. Trustwave urges stronger security.

HackRead
#web#android#mac#git#wordpress#botnet
Qantas: Breach affects 6 million people, “significant” amount of data likely taken

Australian airline Qantas has confirmed a data breach at a third party provider that affects six million customers.

Verizon and T-Mobile Deny Data Breaches as Millions of User Records Sold Online

User claims to sell stolen Verizon and T-Mobile data for millions of users (online Verizon says data is old T-Mobile denies any breach and links to it.

That Network Traffic Looks Legit, But it Could be Hiding a Serious Threat

With nearly 80% of cyber threats now mimicking legitimate user behavior, how are top SOCs determining what’s legitimate traffic and what is potentially dangerous? Where do you turn when firewalls and endpoint detection and response (EDR) fall short at detecting the most important threats to your organization? Breaches at edge devices and VPN gateways have risen from 3% to 22%, according to

PDFs: Portable documents, or perfect deliveries for phish?

A popular social engineering technique returns: callback phishing, or TOAD attacks, which leverage PDFs, VoIP anonymity and even QR code tricks.

Vercel's v0 AI Tool Weaponized by Cybercriminals to Rapidly Create Fake Login Pages at Scale

Unknown threat actors have been observed weaponizing v0, a generative artificial intelligence (AI) tool from Vercel, to design fake sign-in pages that impersonate their legitimate counterparts. "This observation signals a new evolution in the weaponization of Generative AI by threat actors who have demonstrated an ability to generate a functional phishing site from simple text prompts," Okta

GHSA-m43g-m425-p68x: junit-platform-reporting can leak Git credentials through its OpenTestReportGeneratingListener

### Summary This vulnerability affects JUnit's support for writing Open Test Reporting XML files which is an opt-in feature of `junit-platform-reporting`. If a repository is cloned using a GitHub token or other credentials in its URL, for example: ```bash git clone https://${GH_APP}:${GH_TOKEN}@github.com/example/example.git ``` The credentials are captured by `OpenTestReportGeneratingListener` which produces (trimmed for brevity): ```xml <infrastructure> <git:repository originUrl="https://username:token@github.com/example/example.git" /> </infrastructure> ``` ### Details https://github.com/junit-team/junit5/blob/6b7764dac92fd35cb348152d1b37f8726875a4e0/junit-platform-reporting/src/main/java/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.java#L183 I think this should be configurable in some way to exclude select git information or exclude it entirely. ### PoC 1. Clone a repo using a GitHub token as shown above. 2. Enable the listener `junit.platfor...

GHSA-h34r-jxqm-qgpr: juju/utils leaks private key in certs

### Summary Certs generated by v4 contain their private key. ## Details ### Background Recently, I encountered an API in Go that’s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it’s better to address them early. This work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments. ### PoC https://go.dev/play/p/vSW0U3Hq4qk ### Impact [This code](https://github.com/juju/utils/blob/0141ef0ee74a0cac603c5c9e4aff194008722f41/cert/cert.go#L120) (cert.NewLeaf) generates certs with the SubjectKeyId set to `sha512.Ne...

GHSA-xg8h-j46f-w952: Pillow vulnerability can cause write buffer overflow on BCn encoding

There is a heap buffer overflow when writing a sufficiently large (>64k encoded with default settings) image in the DDS format due to writing into a buffer without checking for available space. This only affects users who save untrusted data as a compressed DDS image. * Unclear how large the potential write could be. It is likely limited by process segfault, so it's not necessarily deterministic. It may be practically unbounded. * Unclear if there's a restriction on the bytes that could be emitted. It's likely that the only restriction is that the bytes would be emitted in chunks of 8 or 16. This was introduced in Pillow 11.2.0 when the feature was added.

FBI Warns of Health Insurance Scam Stealing Personal and Medical Data

The Federal Bureau of Investigation (FBI) has issued a warning about a scam where criminals pretend to be…