Security

5484 readers
10 users here now

Confidentiality Integrity Availability

founded 5 years ago
MODERATORS
1
2
 
 

This project implements a FastAPI-based local server designed to load one or more pre-trained NLP models during startup and expose them through a clean, RESTful API for inference.

For example, it leverages the Hugging Face transformers library to load the CIRCL/vulnerability-severity-classification-distilbert-base-uncased model, which specializes in classifying vulnerability descriptions according to their severity level. The server initializes this model once at startup, ensuring minimal latency during inference requests.

Clients interact with the server via dedicated HTTP endpoints corresponding to each loaded model. Additionally, the server automatically generates comprehensive OpenAPI documentation that details the available endpoints, their expected input formats, and sample responsesβ€”making it easy to explore and integrate the services.

The ultimate goal is to enrich vulnerability data descriptions through the application of a suite of NLP models, providing direct benefits to Vulnerability-Lookup and supporting other related projects.

Conceptual architecture

3
4
5
6
7
 
 

Systems

  • Linux
  • Unix
  • MacOS X
8
9
10
11
12
 
 

Today we released Vulnerability-Lookup 2.9.0 with new features, enhancements, and bug fixes.

What's New

Adversarial Techniques from MITRE EMB3D

The Adversarial Techniques from MITRE EMB3D are now integrated into Vulnerability-Lookup as a new source and are correlated with existing security advisories.

This feature was contributed by Piotr Kaminski during the last Hack.lu hackathon. (#129)

MITRE EMB3D

Global CVE Allocation System (GCVE)

GCVE identifiers are now supported in HTML templates and URL parameters,
thanks to the GCVE Python client.
These identifiers can now be used when disclosing a new vulnerability as part of the Coordinated Vulnerability Disclosure (CVD) process, in alignment with NIS 2 requirements. (8bb3d84, 58c394a)

GCVE

Trustworthy Level for Members

Members of a Vulnerability-Lookup instance now have a dynamically calculated
trustworthy level based on profile completeness and verification.
Members affiliated with FIRST.org or European CSIRTs (CNW) are automatically
trusted for operations that would otherwise require administrator approval
(e.g., creating comments).

Changes

  • New API endpoint for MITRE EMB3D. (c0d6b44)
  • Improved the vulnerability disclosure page. (ccfb6b1)
  • Added page arguments to the vulnerability/last endpoint. (ce75a7a)
  • Notification emails now include a random signoff. (#119)
  • Various graphical enhancements. (0878a31)

Fixes

  • Fixed editing of notifications for Organization/Product. (#124)

Changelog

πŸ“‚ 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.9.0

13
14
 
 

🚨 April 2025 Vulnerability Report is out! 🚨

πŸ‘‰ https://www.vulnerability-lookup.org/2025/05/01/vulnerability-report-april-2025/

The most prominent vulnerabilities affect the following products:

  • Ivanti / ConnectSecure
  • Erlang / OTP
  • SAP / SAP NetWeaver

The Continuous Exploitation section highlights several resurgent vulnerabilities (recently exploited at a high rate), including:

  • CVE-2017-17215 (Huawei router)
  • CVE-2015-2051 (D-Link)

Check out the report for more details.

A huge thank you to all contributors and data sources that make this possible! πŸ™Œ

Want to help shape the next report? Join us: πŸ‘‰ https://vulnerability.circl.lu/user/signup

πŸ’» NISDUC Conference

Vulnerability-Lookup will be presented during the fourth NISDUC conference.

πŸ‘‰ https://www.nisduc.eu/

15
 
 

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.

This client can be integrated into software such as Vulnerability-Lookup to provide core GCVE functionalities by adhering to the Best Current Practices.
It can also be used as a standalone command-line tool.

Examples of usage

As a command line tool

First install the gcve client:

$ python -m pip install --user pipx
$ python -m pipx ensurepath

$ pipx install gcve
  installed package gcve 0.6.0, installed using Python 3.13.0
  These apps are now globally available
    - gcve
done! ✨ 🌟 ✨

Pulling the registry locally

$ gcve registry --pull
Pulling from registry...
Downloaded updated https://gcve.eu/dist/key/public.pem to data/public.pem
Downloaded updated https://gcve.eu/dist/gcve.json.sigsha512 to data/gcve.json.sigsha512
Downloaded updated https://gcve.eu/dist/gcve.json to data/gcve.json
Integrity check passed successfully.

Retrieving a GNA

Note: This operation is case sensitive.

$ gcve registry --get CIRCL
{
  "id": 1,
  "short_name": "CIRCL",
  "cpe_vendor_name": "circl",
  "full_name": "Computer Incident Response Center Luxembourg",
  "gcve_url": "https://vulnerability.circl.lu/",
  "gcve_api": "https://vulnerability.circl.lu/api/",
  "gcve_dump": "https://vulnerability.circl.lu/dumps/",
  "gcve_allocation": "https://vulnerability.circl.lu/",
  "gcve_sync_api": "https://vulnerability.circl.lu/"
}

$ gcve registry --get CIRCL | jq .id
1

Searching the Registry

Note: Search operations are case insensitive.

$ gcve registry --find cert
[
  {
    "id": 680,
    "short_name": "DFN-CERT",
    "full_name": "DFN-CERT Services GmbH",
    "gcve_url": "https://adv-archiv.dfn-cert.de/"
  }
]

More information in the Git repository.

16
17
 
 

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.

18
 
 

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

"Traumatized Mr. Incredible" meme format, beneath screenshot of The Register's headline "Uncle Sam abruptly turns off funding for CVE program. Yes, that CVE program". Left panel: "Countering Violent Extremism Task Force?", right panel: "Common Vulnerabilities and Exposures database"

19
20
5
Hacker hacked hackers (www.bleepingcomputer.com)
submitted 1 month ago by Zerush@lemmy.ml to c/security@lemmy.ml
 
 

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

21
 
 

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?

22
23
24
25
view more: next β€Ί