Security

cross-posted from: https://lemmy.ml/post/28680239

The Global CVE (GCVE) allocation system is a new, decentralized approach to vulnerability identification and numbering, designed to improve flexibility, scalability, and autonomy for participating entities.

While remaining compatible with the traditional CVE system, GCVE introduces GCVE Numbering Authorities (GNAs). GNAs are independent entities that can allocate identifiers without relying on a centralised block distribution system or rigid policy enforcement.

Andi's Writeup

The Everest ransomware gang's dark web leak site was hacked and defaced on April 7, 2025, with attackers replacing the content with the message "Don't do crime CRIME IS BAD xoxo from Prague"[^1]. The site subsequently went offline and displayed an "Onion site not found" error[^1].

Flare Senior Threat Intelligence Researcher Tammy Harper suggested the breach likely exploited vulnerabilities in the site's WordPress template[^1]. The attack disrupted Everest's operations, which had evolved since 2020 from data theft extortion to include ransomware deployment and selling network access to other cybercriminals[^2].

Prior to the breach, Everest had claimed over 230 victims on its leak site, including recent attacks on cannabis retailer STIIIZY and increased targeting of U.S. healthcare organizations in 2024[^1][^3]. The group operated as both a ransomware outfit and initial access broker, selling compromised network access to other threat actors[^4].

[^1]: BleepingComputer - Everest ransomware's dark web leak site defaced, now offline

[^2]: CyberSecurityNews - Everest Ransomware Gang Leak Site Hacked and Defaced

[^3]: CyberDaily - Hackers hacking hackers: Everest ransomware leak site defaced

[^4]: TheSecMaster - Everest Ransomware Group: Threat Actor Analysis 2024

Why does Stripe require OAuth tokens to pass through a third party server?

Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?

I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.

Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?

I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API Keys. In fact, we've found that most integrations we've encountered that use Stripe Connect are less secure than using Restricted API Keys because the (private!) tokens are shared with a third party!

I've been using Stripe to handle credit card payments on my e-commerce website for years. Recently, we updated our wordpress e-commerce website and all its plugins. And then we discovered that all credit card payments were broken because our Stripe Payment Gateway plugin stopped allowing use of Restricted API Keys. Instead they only support "Stripe Connect" (which, afaict, is a marketing term for OAuth). This change forced us to do a security audit to make sure that the new authentication method met our org's security requirements. What we found was shocking.

So far we've started auditing two woocommerce plugins for Stripe, and both have admitted that the OAuth tokens are shared with their (the developer's) servers!

One of them is a "Stripe Verified Partner", and they told us that they're contractually obligated by Stripe to use only "Stripe Connect" (OAuth) -- they are not allowed to use good-'ol API Keys.

They also told us that Stripe REQUIRED them to include them in the OAuth flow, such that their servers are given our (very secret!) OAuth Access Keys!

The benefit of normal API Keys, of course, is that they're more secure than this OAuth setup for (at least) two reasons:

1. I generate the API keys myself, and I can restrict the scope of the keys permissions

2. I store the key myself on my own server. It's never transmitted-to nor stored-on any third party servers. Only my server and Stripe's servers ever see it.

Can someone shine a light onto this darkpattern? I understand that standardization is good. OAuth Refresh Keys add security (this service doesn't use them). But why-oh-why would you FORCE OAuth flows that share the (non-expiring) Access Tokens with a third party? And why would you claim that's more secure than good-ol-API-keys?

Does OAuth somehow not support server<-->server flows? Or is it a library issue?

What am I missing?

from the OpenSSH 9.9p2 release announcement:

This release fixes two security bugs.

Security
========

* Fix CVE-2025-26465 - ssh(1) in OpenSSH versions 6.8p1 to 9.9p1
  (inclusive) contained a logic error that allowed an on-path
  attacker (a.k.a MITM) to impersonate any server when the
  VerifyHostKeyDNS option is enabled. This option is off by default.

* Fix CVE-2025-26466 - sshd(8) in OpenSSH versions 9.5p1 to 9.9p1
  (inclusive) is vulnerable to a memory/CPU denial-of-service related
  to the handling of SSH2_MSG_PING packets. This condition may be
  mitigated using the existing PerSourcePenalties feature.

Both vulnerabilities were discovered and demonstrated to be exploitable
by the Qualys Security Advisory team. We thank them for their detailed
review of OpenSSH.

This release of Vulnerability-Lookup includes new features, better monitoring, improvements and fixes.

What's New

Centralized monitoring service

This feature adds log and process heartbeat reporting to a Valkey datastore, enabling centralized monitoring of Vulnerability-Lookup’s system health and its various components.
(#106)

This new feature is essential for monitoring our expanding suite of tools used to collect vulnerability-related information.

It also supports our new email notification service, which alerts platform users about newly discovered vulnerabilities. Additionally, a new admin view has been introduced, allowing real-time monitoring of the collected logs.

CWE and CAPEC

The CAPEC (Common Attack Pattern Enumerations) and CWE (Common Weakness Enumeration) datasets are now accessible through the API. Check out the documentation.
(#98)

Changes

• [API] Added a new 'since' argument to the /api/vunerability/search/<vendor>/<product> endpoint (833d799)
• [Web] Improved administration dashboard (a732ff3, 0258b24, 04f3772)

Fixes

• Missing description on some description from Microsoft feeds (#107)
• Removed duplicate occurences of the string cvssV4_0 in various Jinja filters. (73c4111)
• Few minor fixes.

📂 To see the full rundown of the changes, users can visit the changelog on GitHub: https://github.com/vulnerability-lookup/vulnerability-lookup/releases/tag/v2.6.0

Feedback and Support

If you encounter issues or have suggestions, please feel free to open a ticket on our GitHub repository. Your feedback is invaluable to us!
https://github.com/vulnerability-lookup/vulnerability-lookup/issues/

Follow us on Fediverse/Mastodon

You can follow us on Mastodon and get real time informationa about security advisories:
https://social.circl.lu/@vulnerability_lookup/

You can star the project on GitHub:
https://github.com/vulnerability-lookup/vulnerability-lookup

Or create an account:
https://vulnerability.circl.lu/

We're excited to share the latest features designed to make vulnerability tracking even more efficient.

🚀 What's New

🆕 Email Notifications (Product Watch List)

Stay ahead with hourly, daily, or weekly alerts for new or updated vulnerabilities affecting the vendors and products you care about. Notifications come in both HTML and plain text, with CSV attachments detailing vulnerabilities, sightings, and comments. (#101)

The notification management interface

Future releases will allow users to create notifications by specifying just a vendor, optionally a version, and to be notified about new sightings related to a product or vulnerability.

Various email notifications

The screenshot below shows a list of notifications aggregated in an email client. It's easy to aggregate messages by product / vendor.

🆕 Fraunhofer FKIE NVD Feeder

FKIE NVD Feeder is now operating as a standalone source. (b1e86d8)

🆕 Sightings Import/Export

Manage your sightings via the admin interface with new import/export capabilities. (23cfed2)

🆕 New API Endpoint

Quickly retrieve recently added or updated vulnerabilities since a specific date for better automation and integration. (eccd34d)

🛠️ Changes

• Harmonized pagination mechanism of the API and made it more simple to use (using page numbers instead of using offsets) (46ce344)
• The evolution chart is now taking advantage of the pagination in order to get more data (ada62e2)
• Added an input integer slider in order to let the user dynamically set the minimum number of sightings in the evolution table (cea65b7)
• Implemented a function to check if a domain name exists in the block list, as defined in the website's configuration file (a2e04b3)
• Various improvements to the home page (48cbaed)
• log entry when a shutdown key is present on start (fd18d45)
• Various improvements to the API

📂 To see the full rundown of the changes, users can visit the changelog on GitHub: https://github.com/vulnerability-lookup/vulnerability-lookup/releases/tag/v2.5.0

🙏 Thank you very much to all the contributors and testers!

Tips

Filtering your email notifications

Notification emails from Vulnerability-Lookup include custom SMTP headers:

• X-Mailer: Vulnerability-Lookup
• X-Category: Security Advisory

This allows you to easily create rules or filters in your email client, as shown below. Additionally, you can set up more fine-grained rules based on the email subject.

[]

Creation of a new notification

Example of a notification with sightings

for readers missing the significance of the number 4 in the proof of concept: to demonstrate this vulnerability the researchers created a microcode update which replaces the "hardware" random number generator behind the RDRAND instruction with an implementation of xkcd#221 😭

We are glad to announce the immediate availability of vulnerability-related observations from The Shadowserver Foundation within Vulnerability-Lookup.

This milestone wouldn’t have been possible without Piotr Kijewski. We developed a new sighting client, ShadowSight. This new client gathers vulnerability-related data directly from The Shadowserver Foundation, then reports the collected data to the Vulnerability-Lookup API as sightings.

ShadowSight leverages insights on common vulnerabilities and exploited vulnerabilities from Shadowserver’s honeypot source. Source code of ShadowSight is available:

👉 https://github.com/CIRCL/ShadowSight

Explore our sightings collected from this source:

• Exploited vulnerabilities (type: exploited):
  https://vulnerability.circl.lu/sightings/?query=honeypot%2Fexploited-vulnerabilities
• Common vulnerabilities (type: seen):
  https://vulnerability.circl.lu/sightings/?query=honeypot%2Fcommon-vulnerabilities

The Shadowserver Foundation remains a cornerstone resource for security researchers, providing an extensive wealth of data on real-world exploits and their associated vulnerabilities, complete with daily statistics and geographical insights.

Widely used by incident response teams, security researchers, analysts, and other cybersecurity professionals, Shadowserver is recognized as a highly credible and impactful project in the cybersecurity landscape. The Shadowserver Foundation delivers particularly valuable insights into security issues, including vulnerabilities in unpatched IoT devices, various types of internet-facing services, and even services that should not be exposed to the internet.

For us, it has quickly become a reliable sources for sightings. It's also a way to diversify our sources and improve situational awareness.

🔗 Explore all our sighting sources (such as Mastodon, Bluesky, MISP, etc.) and tools here:

👉 https://www.vulnerability-lookup.org/tools/#sightings

📖 References

• https://www.shadowserver.org/
• https://vulnerability.circl.lu/
• https://github.com/cve-search/vulnerability-lookup
• https://github.com/CIRCL/ShadowSight
• https://www.vulnerability-lookup.org/documentation/sightings.html

🤝 Contribute

If you want to benefit from more features of Vulnerability-Lookup like sharing comments, bundles, or sightings, you can create an account to the instance operated by CIRCL:

👉 https://vulnerability.circl.lu/user/signup