Is This Popular Package Safe?
GeekWala deliberately keeps a package's individual security page out of search results once it has zero known vulnerabilities — an empty vulnerability list is thin content, and search engines (correctly) don't want to rank pages that say nothing. This page is where that decision is reversed: a single, real, regularly re-checked list of popular packages across 8 ecosystems and their current vulnerability status, so "is lodash safe" or "is requests vulnerable" has somewhere on GeekWala to land.
npm (Node.js)
npm hosts the JavaScript/TypeScript ecosystem — the packages listed below are among the most widely installed in the Node.js world, pulled in directly or transitively by countless downstream projects. npm's install-time hooks and deep transitive trees make prototype pollution and dependency-confusion attacks a recurring risk class here, which is exactly why a live, re-checked status matters more than a one-time badge.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| react | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| chalk | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| lodash | Vulnerabilities found | August 23, 2026 | View report |
| express | Vulnerabilities found | August 23, 2026 | View report |
| axios | Vulnerabilities found | August 23, 2026 | View report |
PyPI (Python)
PyPI serves the Python ecosystem. The packages below anchor huge swaths of the data-science, web, and automation tooling landscape, and many of them ship native extensions or execute arbitrary code at install time — the same install-time-code risk profile npm has, in a different language.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| requests | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| numpy | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| flask | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| django | Vulnerabilities found | August 23, 2026 | View report |
Maven Central (Java)
Maven Central serves the Java/JVM ecosystem. These libraries sit near the base of enterprise Java dependency trees, often pulled in transitively by a build tool rather than declared directly, which is exactly why an aggregate status check like this one is useful — most teams never audit them by name.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| org.springframework:spring-core | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| com.google.guava:guava | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| org.apache.commons:commons-lang3 | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| com.fasterxml.jackson.core:jackson-databind | Vulnerabilities found | August 23, 2026 | View report |
Go Modules
Go Modules packages below are staples of cloud-native and CLI tooling written in Go. Compiled, statically-linked Go binaries see fewer supply-chain typosquats than dynamically-loaded ecosystems, but memory-safety and FFI issues in C-bound dependencies still surface here.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| github.com/spf13/cobra | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| github.com/stretchr/testify | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| golang.org/x/text | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| github.com/gin-gonic/gin | Vulnerabilities found | August 23, 2026 | View report |
crates.io (Rust)
crates.io serves the Rust ecosystem. These crates are foundational to async runtimes, CLIs, and serialization in Rust projects — Rust's memory-safety guarantees reduce one risk class but don't eliminate logic bugs, unsafe-block misuse, or supply-chain compromise of the crate itself.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| serde | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| tokio | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| clap | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
RubyGems (Ruby)
RubyGems serves the Ruby ecosystem, anchored heavily by Rails-adjacent tooling. Gems with native C extensions or that shell out to system commands carry the same install-time-execution risk profile as npm and PyPI.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| rspec | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| rails | Vulnerabilities found | August 23, 2026 | View report |
| devise | Vulnerabilities found | August 23, 2026 | View report |
| sidekiq | Vulnerabilities found | August 23, 2026 | View report |
NuGet (.NET)
NuGet serves the .NET ecosystem. These packages are common in enterprise C#/.NET applications, where a compromised or vulnerable transitive dependency can sit undetected for a long time in a codebase without routine dependency auditing.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| Serilog | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| Dapper | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| Newtonsoft.Json | Vulnerabilities found | August 23, 2026 | View report |
| AutoMapper | Vulnerabilities found | August 23, 2026 | View report |
Packagist (PHP)
Packagist serves the PHP ecosystem, including the Laravel and Symfony framework families. PHP dependency trees tend to be shallower than npm's, but a single widely-used package like the ones below can still touch a very large share of production PHP applications.
| Package | Status | Last Checked | Details |
|---|---|---|---|
| monolog/monolog | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| symfony/console | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| guzzlehttp/guzzle | No known vulnerabilities | August 23, 2026 | No vulnerabilities found |
| laravel/framework | Vulnerabilities found | August 23, 2026 | View report |
Why individual pages don't show up for these packages
Every package GeekWala tracks gets its own detail page at /package/{ecosystem}/{name}. When that page has real vulnerabilities to report, it's a genuinely useful, unique page and it gets indexed. When a package has zero known vulnerabilities, that page would say almost nothing — "no known vulnerabilities" repeated across millions of near-identical pages is exactly the kind of thin, auto-generated content search engines penalize sitewide. So GeekWala marks those individual pages noindex rather than mass-publish filler. This page is the deliberate exception: one substantive, regularly-refreshed page that answers the same underlying question — "is this package currently safe?" — for a curated set of the packages people actually ask about, without minting thousands of thin pages to do it.
Methodology — how "clean" is determined
Every row above is computed live from the same vulnerability database that powers GeekWala's scanner, not a hand-maintained list. A package is marked "no known vulnerabilities" only when it has zero matching rows in GeekWala's OSV-sourced vulnerability index at the moment this page renders. The database is refreshed from the OSV project on a recurring schedule per ecosystem — the "Last Checked" column above shows when that ecosystem's data was most recently synced, not a fixed publish date. If a new CVE lands against any package on this page, the next sync will surface it here and on that package's own report page — this page has no separate, independently-maintained "safe" list that could drift out of sync with reality.
Why This Page Instead Of A Generic Package Directory
Some vulnerability databases publish a page for essentially every package that has ever been published, regardless of whether it currently has anything to say — a page for a perfectly clean package looks nearly identical to a page for one with a critical, actively-exploited flaw, and the visitor has to read the whole page to tell the difference. GeekWala takes the opposite approach: an individual package page only exists in search results when it has real vulnerability data to report, and this hub exists specifically to answer the "is it safe" question for the much larger set of packages that currently have nothing to report.
That also means the badge you see above is never a static marketing claim. Every "no known vulnerabilities" badge is the same live query GeekWala's scanner runs against your own lockfile — ranked, where relevant, against EPSS exploit-probability scores and the CISA Known Exploited Vulnerabilities catalog rather than raw CVSS severity alone, so a flagged package here reflects real-world exploitation signal, not just a theoretical score.
Read another way: a per-package "safe" page is a single data point about a single dependency, checked once, at whatever moment a visitor happens to land on it. This hub is the same underlying check, run continuously against every package listed here, surfaced in one place a developer can bookmark and revisit — before adopting a new dependency, during a periodic security review, or right after a headline CVE against a popular package makes everyone double-check their own lockfile. The individual /package/{ecosystem}/{name} pages and this hub are two views of the same live data, not two separate sources of truth that could quietly drift apart.
Common Questions
What if a "clean" package gets a CVE tomorrow?
This page has no static content to go stale. Every status badge is computed from live data on each request, cached for at most an hour. Once GeekWala's ingestion pipeline picks up a new advisory against a listed package, that package drops out of the "clean" list here and its own /package/{ecosystem}/{name} page becomes indexable again — you can follow the "View report" link on any flagged row above to see exactly what was found.
How were these 32+ packages chosen?
This is a curated list of widely-used packages across every ecosystem GeekWala scans — npm, PyPI, Packagist, Maven, Go, crates.io, RubyGems, and NuGet — the kind of dependency almost every project in that language pulls in, directly or transitively. It is not exhaustive: for a full check against your own dependencies, use the free scanner below rather than searching for your exact package here.
Does "no known vulnerabilities" mean the package is bug-free?
No. It means no vulnerability matching that package currently exists in the OSV-sourced database GeekWala scans against. Zero-day and unreported issues, misuse of the package, and vulnerabilities in packages it depends on transitively are all outside what this status reflects — scan your actual lockfile for the full picture of your dependency tree.
My package isn't listed here — is it safe?
This page only covers a curated set of high-traffic packages, not the millions published across every ecosystem. Search the full scanner hub or upload your lockfile to the free scanner to check any package by name, including ones not featured on this page.
Why not just show a "safe" badge for every clean package, like other package registries do?
Because a static badge is exactly the kind of claim that goes stale the moment a new advisory lands. Some competing vulnerability databases publish an individual page for essentially any package name a visitor types, regardless of whether that package currently has anything worth reporting — which answers the "is it safe" query at the cost of ranking near-empty pages alongside genuinely substantive ones. GeekWala's tradeoff is the opposite: keep the thin, zero-vulnerability individual pages out of search entirely, and concentrate the reassurance-intent answer here, on one page that is re-derived from live data on every render instead of cached as a fixed claim.
Check Your Own Dependencies, Not Just Popular Ones
Upload a lockfile and get every dependency's real vulnerability status — ranked by EPSS exploit probability and CISA KEV, not just CVSS severity.