New open-source package security advisories (weekly)

Usage commercial OKÀ jourLicence: CC-BY-4.0

Échantillon seulementTélécharger l'exemple CSV Télécharger l'exemple JSONLignes d’exemple seulement (jusqu’à 20) — pas le jeu de données complet.

Weekly digest of newly published GitHub Security Advisories (GHSA) that map to real package ecosystems (pip, npm, go, maven, composer, crates.io, ...). Every advisory published in the trailing 7 complete days with at least one package ``vulnerabilities`` mapping is deduplicated on ghsa_id, normalized across ecosystems (sorted ecosystem:name package set, CVE id, CWE list, affected version ranges, fix availability), and enriched: GitHub severity + CVSS base score -> 0-10 severity_score, GitHub-attached EPSS score/percentile, and a match against a curated ~170-package data/ML universe (ml_stack flag, ml_categories, package_criticality tier 1 foundational .. 3 niche). A documented 0-100 risk_score = 100*(0.50*severity + 0.30*EPSS percentile + 0.20*unpatched) is ranked as risk_rank (ties: CVSS desc, ghsa_id asc) and bucketed into risk_tier p1..p4. Advisories without a package mapping (CVE-imported records with no dependency-triage value) and withdrawn advisories are excluded. Week-granular as-of stamping makes same-window re-runs hash-identical. Columns: snapshot week, fetch timestamp, GHSA id, CVE id, publish and update timestamps, summary, description, severity, CVSS score/vector, EPSS score/percentile, CWEs, packages, ecosystems, ML-stack flag/categories/criticality, fix flag, affected ranges, references, source URL, risk score/tier/rank. Primary key: (snapshot_week, ghsa_id). Cadence: weekly. Nullability: cve_id null when the advisory carries no CVE identifier; cvss_score null when neither cvss.score nor cvss_severities carries a numeric score (severity map used instead); epss_* null when GitHub attaches no EPSS. Caveats: risk_score is a triage heuristic, not a quantified risk measure; version ranges are GitHub-curated and occasionally coarse; the ML universe is curated, not exhaustive. The underlying GitHub Advisory Database is CC-BY-4.0 (commercial_use = yes, attribution required); severity scores, EPSS values and the risk ranking are derived signals computed by this connector. Sample use: filter ml_stack = 1 for the advisories touching your data/ML dependencies, order by risk_rank for what to patch first.

Les titres et les descriptions proviennent des sources de données, en anglais.

Source: GitHub Security Advisories, weekly digest (agent-curated)
Lignes: 205
Colonnes: 26
Cadence de la source: Hebdomadaire
Dernière actualisation: 25 sept. 2026
Thème: technology

Colonne	Type	Description
snapshot_week	string	ISO week of the trailing-7-day window end (YYYY-Www); the logical snapshot identity together with ghsa_id. (unit: ISO week)
fetched_at	string	Fetch timestamp, week-granular: the window end at 00:00 UTC. Same-window re-runs produce identical snapshots. (unit: ISO datetime)
ghsa_id	string	GitHub Security Advisory identifier (GHSA-xxxx-xxxx-xxxx), uppercased; the primary row identity. Malformed ids are dropped, never repaired. (unit: id)
cve_id	string	Associated CVE identifier, uppercased; null when the advisory carries no CVE. (unit: id)
published_at	string	When GitHub published the advisory (ISO datetime). (unit: ISO datetime)
updated_at	string	When GitHub last updated the advisory (ISO datetime). (unit: ISO datetime)
summary	string	GitHub's one-line advisory summary; whitespace-collapsed, emails stripped. CC-BY-4.0 GitHub Advisory Database. (unit: text)
description	string	Full advisory description; whitespace-collapsed, emails stripped. CC-BY-4.0 GitHub Advisory Database. (unit: text)
severity	string	GitHub's coarse severity: critical, high, medium, low, or unknown. (unit: category)
cvss_score	float	CVSS base score 0-10 (cvss.score, else the max of cvss_severities v3/v4); null when no numeric score exists — then the coarse severity map feeds risk_score instead. (unit: score)
cvss_vector	string	CVSS vector string behind cvss_score; null when no numeric score exists. (unit: vector)
epss_score	float	EPSS exploit-probability score attached by GitHub (0-1); null when absent. (unit: probability)
epss_percentile	float	EPSS percentile attached by GitHub (0-1); feeds risk_score (0 when absent). (unit: proportion)
cwes	string	Comma-joined CWE identifiers from the advisory; empty when none are listed. (unit: ids)
packages	string	Sorted, deduplicated ecosystem:name package set affected by the advisory. (unit: names)
ecosystems	string	Sorted unique package ecosystems among the advisory's vulnerabilities (pip, npm, go, maven, composer, crates, ...). (unit: names)
ml_stack	integer	1 when any affected package matches the curated data/ML universe, else 0. (unit: flag)
ml_categories	string	Comma-joined data/ML categories of the matched packages (serving, llm-tooling, ...); empty when ml_stack = 0. (unit: categories)
package_criticality	integer	Max criticality weight over the advisory's matched ML packages: 3 = foundational (tier 1), 2 = widely deployed, 1 = niche; 0 when no package matches the universe. (unit: level)
has_fix	integer	1 when any vulnerability lists patched versions or a first patched version, else 0. (unit: flag)
affected_ranges	string	Semicolon-joined per-package vulnerable version ranges (ecosystem:name range), as curated by GitHub. (unit: ranges)
references	string	Up to 3 advisory reference URLs, space joined; falls back to the advisory page. (unit: urls)
source_url	string	Canonical advisory page (github.com/advisories/GHSA-...); per-row provenance. (unit: url)
risk_score	float	Dependency-triage score, 0-100: 100(0.50severity + 0.30EPSS percentile + 0.20unpatched). A triage heuristic — not a quantified risk measure. (unit: score)
risk_tier	string	risk_score buckets: p1 (>= 75), p2 (>= 50), p3 (>= 25), p4 (below). (unit: category)
risk_rank	integer	Rank by risk_score descending (1 = patch first); ties broken by CVSS desc (missing last), then ghsa_id. (unit: rank)

10 premières lignes d’exemple — un aperçu, pas le jeu de données complet.

snapshot_week	fetched_at	ghsa_id	cve_id	published_at	updated_at	summary	description	severity	cvss_score	cvss_vector	epss_score	epss_percentile	cwes	packages	ecosystems	ml_stack	ml_categories	package_criticality	has_fix	affected_ranges	references	source_url	risk_score	risk_tier	risk_rank
2026-W39	2026-09-24T00:00:00+00:00	GHSA-26VP-8GXG-V4PG	CVE-2025-53837	2026-09-18T15:05:13Z	2026-09-18T15:05:15Z	org.xwiki.rendering:xwiki-rendering-xml has an Eval Injection issue	### Impact Any user who can edit their own user profile or any other document can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The reason is that rendering output is included as content of HTML macros without further escaping and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights. This can be demonstrated by adding an object of type `XWiki.UIExtensionClass` to a document with content `{{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}{{/html}}`, extension point id `org.xwiki.platform.html.head`, extension id `org.xwiki.myuser.test` and extension scope "current user". When opening `<xwiki-server>/xwiki/bin/view/Main/?sheet=CKEditor.ContentSheet&xpage=plain` where `<xwiki-server>` is the URL of the XWiki installation, the output should start with `{{/html}} {{cache}}{{groovy}}println(1){{/groovy}}{{/cache}}` and not with ` 1</p>`. This escaping was always missing at least in XWiki syntax version 2, it is definitely exploitable in XWiki 3.3 Milestone 1 via the user profile (not through extension points), though this has also been fixed by a separate patch, see the [advisory](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-x764-ff8r-9hpx). Exploitable extension points include [`org.xwiki.platform.search.ui.docdoesnotexist`](https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/Suggestions%20for%20Document%20Does%20Not%20Exist/) which has been added in XWiki 8.3 Milestone 1. ### Patches This has been patched in XWiki 14.10.2 and 15.0 RC1 by making sure that rendering output cannot close the surrounding HTML macro. ### Workarounds It is in principle possible to add escaping to all places where rendering output is used in wiki documents but at the moment there is no list of them. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:)	critical	9,9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H	0,006	0,494	CWE-95	maven:org.xwiki.rendering:xwiki-rendering-xml	maven	0	—	0	1	maven:org.xwiki.rendering:xwiki-rendering-xml < 14.10.2	https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-26vp-8gxg-v4pg https://github.com/xwiki/xwiki-rendering/commit/92bc8095ed3acce15ab200c8525e1623b4898be5 https://github.com/xwiki/xwiki-rendering/releases/tag/xwiki-rendering-14.10.2	https://github.com/advisories/GHSA-26vp-8gxg-v4pg	64,31	p2	1
2026-W39	2026-09-24T00:00:00+00:00	GHSA-2VH9-42VM-XMV2	CVE-2025-66455	2026-09-18T17:03:56Z	2026-09-21T16:20:07Z	LMDeploy has Remote Code Execution by Pickle Deserialization via handle_zmq_recv in lmdeploy/lmdeploy/pytorch/disagg/conn/engine_conn.py	## Summary LMDeploy's PyTorch DistServe/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements `recv_pyobj()` using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the `POST /distserve/p2p_connect` HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow. ## Affected components - HTTP entry point: `lmdeploy/serve/openai/endpoints/distserve.py`, `POST /distserve/p2p_connect` - Attacker-controlled peer address: `DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address` - Vulnerable receiver: `lmdeploy/pytorch/disagg/conn/engine_conn.py`, `EngineP2PConnection.handle_zmq_recv()` - Unsafe operation: `recv_pyobj()`, which performs pickle deserialization ## Vulnerable data flow 1. A caller submits a DistServe P2P connection request containing a ZeroMQ address. 2. The LMDeploy engine connects its ZeroMQ PULL socket to that address. 3. `handle_zmq_recv()` receives messages using `recv_pyobj()`. 4. A malicious peer sends a crafted pickle object. 5. Python code executes during deserialization, before LMDeploy can perform any type or field validation. A type check performed after `recv_pyobj()` cannot mitigate this issue because pickle payload execution occurs during deserialization. ## Impact Successful exploitation allows arbitrary code execution as the LMDeploy serving process. This can expose model weights, prompts, credentials, attached storage, cluster-network services, and host or GPU resources. An attacker may also modify or terminate the serving process. ## Affected versions Affected versions: - `lmdeploy >= 0.9.2, < 0.16.0` The vulnerable P2P receiver was introduced in commit `b0b705f7`. ## Remediation The issue was fixed by replacing the pickle-based ZeroMQ protocol with JSON serialization: - `send_pyobj()` was replaced with `send_json()`. - `recv_pyobj()` was replaced with `recv_json()`. - Received objects are validated using the `DistServeCacheFreeRequest` Pydantic schema before use. - Invalid or off-schema messages are rejected without terminating the receive loop. Fix commit: https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2 The fix was released in LMDeploy 0.16.0. ## Workarounds Users who cannot upgrade immediately should: - Prevent untrusted clients from reaching `/distserve/*` endpoints. - Restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks. - Configure API-key authentication. - Block arbitrary outbound ZeroMQ connections from serving nodes. These measures reduce exposure but do not make pickle deserialization safe. Upgrading to LMDeploy 0.16.0 or later is recommended.	critical	9,8	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	0,007	0,508	CWE-502	pip:lmdeploy	pip	1	serving	1	1	pip:lmdeploy >= 0.9.2, < 0.16.0	https://github.com/InternLM/lmdeploy/security/advisories/GHSA-2vh9-42vm-xmv2 https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2 https://github.com/InternLM/lmdeploy/releases/tag/v0.16.0	https://github.com/advisories/GHSA-2vh9-42vm-xmv2	64,24	p2	2
2026-W39	2026-09-24T00:00:00+00:00	GHSA-RR49-F9G6-C9R5	CVE-2026-57149	2026-09-23T13:55:47Z	2026-09-23T13:55:49Z	plone.app.portlets Vulnerable to Remote Code Execution via TALES Injection	### Impact The Classic portlet (plone.app.portlets.portlets.classic) used its user-supplied template/macro fields to build a TALES path expression that was then evaluated by the TAL path() helper. Because the value was interpreted as a full TALES expression, a user able to add or edit a Classic portlet could supply a crafted value that escapes simple path traversal and is evaluated as arbitrary code. This is exploitable by any authenticated user who can configure a Classic portlet - which, with the default role map, includes regular users on their personal dashboard. The result is code execution in the context of the Plone process, i.e. a privilege escalation across the trust boundary between an authenticated web user and the server-side process. ### Patches The problem has been patched in `plone.app.portlets` * For Plone 6.2, upgrade to `plone.app.portlets` 7.0.2. * For Plone 6.1, upgrade to `plone.app.portlets` 6.0.4. * For Plone 6.0, upgrade to `plone.app.portlets` 5.0.8. ### Workarounds If upgrading is not immediately possible: - Restrict who can manage portlets: remove the `plone.app.portlets.ManageOwnPortlets` permission from untrusted roles, and limit Manage portlets to trusted administrators (usually this is already restricted to the Manager and Site Administrator roles). - Where the Classic portlet is not needed, unregister it so it cannot be added. This would need to be done by editing a `portlets.xml` in your own code, so it is not a quick fix. - You could also effectively disable showing the classic portlet by customising its template. In the Zope Management Interface go to the `portal_view_customizations` tool, locate the `classic.pt` template and click it. Click the Customize button. Remove all text and replace it with `<div>The classic portlet was disabled.</div>`. (This is not a recommended way of customising a template, but in this case it is quite effective.) ### Credits Discovered by Giuseppe Caruso, and reported to the [Plone/Zope Security Team](mailto:). Thanks!	critical	9,9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H	0,006	0,483	CWE-95	pip:plone.app.portlets	pip	0	—	0	1	pip:plone.app.portlets >= 5.0.0, <= 5.0.7; pip:plone.app.portlets >= 6.0.0, <= 6.0.3; pip:plone.app.portlets >= 7.0.0, <= 7.0.1	https://github.com/plone/plone.app.portlets/security/advisories/GHSA-rr49-f9g6-c9r5 https://nvd.nist.gov/vuln/detail/CVE-2026-57149 https://github.com/plone/plone.app.portlets/commit/1d9cacacfad9ed08b890dadc6e75741e295dc151	https://github.com/advisories/GHSA-rr49-f9g6-c9r5	63,99	p2	3
2026-W39	2026-09-24T00:00:00+00:00	GHSA-JJQ7-M736-W977	CVE-2026-77602	2026-09-23T18:57:24Z	2026-09-23T18:57:24Z	OpenC3 COSMOS: Authenticated remote code execution via the user-writable config overlay (table definitions, cmd/tlm definitions, and script suites)	### Summary COSMOS reads configuration from a user-writable overlay (`targets_modified/`) before the read-only plugin-installed `targets/` tree, and the config subsystem executes code on those files: `ConfigParser` renders every file as ERB by default, a `GENERIC_READ_CONVERSION` / `GENERIC_WRITE_CONVERSION` block is evaluated as code by `GenericConversion` (Ruby and Python), and the Script Runner suite analysis `require`s a procedure file. An authenticated user can write into `targets_modified/` below the admin tier (the storage-upload endpoint exempts that area from the admin gate, and the screen-save endpoint stores its body verbatim there), so the same root cause is reachable through several features, each giving arbitrary code execution on a COSMOS server. Three vulnerable routes were identified, all reachable by an authenticated non-admin user (in the open-source edition `authorize` ignores the permission string, so any authenticated user qualifies): 1. Table definitions (immediate). `tables#generate\|report\|load` reads a definition from `targets_modified/` and ERB-renders it and evaluates its `GENERIC__CONVERSION` block in the `cmd-tlm-api` container. 2. Command/telemetry definitions* (persistent). A file written to `targets_modified/<TARGET>/cmd_tlm/` is overlaid by `System.setup_targets` and processed by `PacketConfig` in the decom/multi microservices: ERB-rendered in the Ruby implementation, and GENERIC-evaluated in both the Ruby and Python implementations (the Python `ConfigParser` does not run ERB). It executes on the next microservice (re)start. 3. Script Runner suites (immediate). A procedure written to `targets_modified/<TARGET>/procedures/` is `require`d by the suite analysis, reachable at the read-only `script_view` tier through `scripts#body` and `running_script#show` (the analysis subprocess is spawned when `OPENC3_SERVICE_PASSWORD` is configured, which it is in the shipped `.env`). ### Details Root cause. `TargetFile.body` (Ruby `openc3/lib/openc3/utilities/target_file.rb`, Python `openc3/python/openc3/utilities/target_file.py`) reads `{scope}/targets_modified/{name}` before `{scope}/targets/{name}`. The storage-upload endpoint `storage_controller.rb get_upload_presigned_request` is gated at `system_set` and exempts `targets_modified/` and `tmp/` from its `admin` check (so a write there is not admin-gated); for a target path it additionally calls `authorize_bucket_path`, which in the permission-enforcing edition requires `tlm` on the target, while in the open-source edition `authorize` ignores the permission string entirely. `screens_controller.rb create` (`system_set`) stores its request body verbatim under `targets_modified/<target>/screens/`. So a non-admin can place files in the overlay. The config subsystem then executes them. Sink 1, ERB. `ConfigParser#parse_file` renders the file as ERB before parsing (`run_erb` defaults to true): ```ruby # openc3/lib/openc3/config/config_parser.rb:402 output = ERB.new(File.read(filename)...comment_erb(), trim_mode: "-").result(...) ``` Reached for table definitions via `tables_controller.rb` -> `Table.get_definitions` -> `TableConfig.process_file` -> `parse_file`, and for cmd/tlm definitions via `System.setup_targets` (`system.rb`, whose overlay loop copies `targets_modified/<T>/cmd_tlm/*` over the read-only files) -> `PacketConfig#process_file` -> `parse_file`. Sink 2, GENERIC conversion. `PacketConfig`/`TableConfig` build a `GenericConversion` from a `GENERIC_READ_CONVERSION_START .. END` / `GENERIC_WRITE_CONVERSION_START .. END` block, and `GenericConversion#call` evaluates it (independent of ERB): ```ruby # openc3/lib/openc3/conversions/generic_conversion.rb (call) eval(@code_to_eval) # Python openc3/python/openc3/conversions/generic_conversion.py (call): compile()/exec()/eval() ``` The read conversion fires on `tables#report`/`load` and during telemetry decom; the write conversion fires on `tables#generate` and on `restore_defaults`. Sink 3, suite require. The Script Runner suite analysis executes the file: ```ruby # openc3-cosmos-script-runner-api/scripts/run_suite_analysis.rb:24 require ARGV[1] # runs all top-level code of the supplied file ``` reached from `Script.process_suite`, invoked by `scripts#body` and `running_script#show` (both `script_view`) and `scripts#create` (`script_edit`) when the file matches the suite pattern. Permission tiers. Writing the payload needs `system_set` (screen save, storage upload) or `script_edit` (script create); triggering needs `system` (tables) or `script_view` (suite). These are below the tiers where COSMOS gates code execution elsewhere (plugin install requires `admin`, running a script requires `script_run`). ### PoC Table definition path, against a standard stack. Benign payload writes `id` to a marker file. This PoC uses the open-source password login; in the permission-enforcing edition substitute a bearer token for a user holding the permissions noted above. ```bash BASE=http://localhost:2900/openc3-api # adjust to your deployment TOKEN=$(curl -s -X POST "$BASE/auth/verify" -H 'Content-Type: application/json' -d '{"password":"<your password>"}') # 1) Write the payload into targets_modified/ via the screen save endpoint. curl -s -X POST "$BASE/screen" -H "Authorization: $TOKEN" \ --data-urlencode 'scope=DEFAULT' --data-urlencode 'target=INST' --data-urlencode 'screen=poc' \ --data-urlencode $'text=SCREEN AUTO AUTO 1.0\n<%= File.write("/tmp/erb_rce_poc", `id`) %>\nLABEL poc' # 2) Trigger by pointing a table action at that file. curl -s -X POST "$BASE/tables/generate" -H "Authorization: $TOKEN" \ --data-urlencode 'scope=DEFAULT' --data-urlencode 'definition=INST/screens/poc.txt' ``` Then in the cmd-tlm-api container: `cat /tmp/erb_rce_poc` shows `uid=1001(openc3) ...`. The `tables/generate` request returns HTTP 500 (the screen lines are not valid table keywords); the marker shows the code already ran. The same outcome without ERB, using the GENERIC sink, on the same `tables/generate` trigger: ``` TABLE "data" BIG_ENDIAN KEY_VALUE "poc" APPEND_PARAMETER "item1" 8 UINT 0 255 0 "Item" GENERIC_WRITE_CONVERSION_START `id > /tmp/erb_rce_poc` 0 GENERIC_WRITE_CONVERSION_END ``` cmd/tlm path: upload a telemetry definition containing the same ERB or GENERIC block to `targets_modified/<TARGET>/cmd_tlm/<file>.txt` via the storage-upload presigned request (`system_set`), then the code runs in that target's decom microservice on its next restart. Suite path: write a suite-shaped procedure to `targets_modified/<TARGET>/procedures/<x>.rb` and call `scripts#body` on it at `script_view`. The ERB table chain was confirmed end to end over HTTP against a booted Rails and puma instance. ### Impact Arbitrary code execution as the `openc3` user in the `cmd-tlm-api` container and the per-target decom microservices and the script-runner. Those processes hold the Redis and bucket credentials and sit on the internal service network, so the executed code acts with that authority over configuration, telemetry, and command data across scopes. The API is served through Traefik, which the shipped compose binds to `127.0.0.1:2900`, so a default single-host install is reachable only from the host; a multi-user deployment exposes the web port, and the `AV:N` rating reflects that standard remote-operator exposure. All paths require valid authentication, and the triggering permissions (`system`/`system_set`/`script_view`) are below the `admin`/`script_run`/plugin-install tiers where COSMOS gates code execution. In the open-source edition `authorize` checks only token validity and does not enforce the permission string, so any authenticated user can perform these requests. ### Suggested fix The fix is to treat the user-writable overlay as data, never code, and to gate the writers, applied uniformly: - Load table and cmd/tlm definitions for code-execution paths from the read-only `targets/` tree only, or parse the `targets_modified` overlay with ERB disabled (`run_erb=false`); dynamically-created packet definitions are structural and never need ERB, so this does not regress that feature. - Allow only admin and the server-side dynamic-packet mechanism to write a `cmd_tlm` overlay; reject non-canonical object keys so a positional path check cannot be bypassed by a key the object store normalizes differently. - Run the Script Runner suite analysis (which executes the file) only at the `script_run` tier, at every entry point. - Mirror the definition-read change in the Python implementation.	critical	9,9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H	0,006	0,45	CWE-94	rubygems:openc3	rubygems	0	—	0	1	rubygems:openc3 >= 5.1.0, <= 7.2.1	https://github.com/OpenC3/cosmos/security/advisories/GHSA-jjq7-m736-w977 https://github.com/OpenC3/cosmos/pull/3488 https://github.com/OpenC3/cosmos/commit/71943352a28128ef3e7e894319d97a656b5cd4f2	https://github.com/advisories/GHSA-jjq7-m736-w977	63	p2	4
2026-W39	2026-09-24T00:00:00+00:00	GHSA-J43X-5HJQ-RGXF	CVE-2026-54892	2026-09-23T14:00:22Z	2026-09-23T14:00:23Z	Plug: quadratic-time decoding of nested query/body parameters enables denial of service	### Summary Plug's nested-parameter decoder (`Plug.Conn.Query`) parses URL-encoded keys in time quadratic in their bracket-nesting depth. Any unauthenticated remote attacker that can reach a Plug-based HTTP endpoint can pin a BEAM scheduler for minutes with a single small request. ### Details For a key like `a[a][a]...=1`, `Plug.Conn.Query.split_keys/6` (in `lib/plug/conn/query.ex`) builds an accumulator of `:binary.part` prefixes (`a`, `a[a]`, `a[a][a]`, …) that grow ~3 bytes per level. `Plug.Conn.Query.insert_keys/3` then does one `Map.put` per level keyed on that growing prefix, hashing the full byte range each time, and `Plug.Conn.Query.finalize_pointer/2` repeats the prefix-keyed walk to materialize the structure. Total cost is `O(N²)` in nesting depth. The same code path handles query strings, `application/x-www-form-urlencoded` bodies, and multipart field names via `Plug.Conn.Query.decode/4` and `decode_each/2`. The default `Plug.Parsers.URLENCODED` cap is 1 MB (~333,000 nesting levels), but `Plug.Parsers` accepts urlencoded payloads up to its overall body limit (20 MB by default), so an attacker can scale the per-request work well beyond the urlencoded-specific cap. The decoder shows ~4× scaling per 2× input (16k levels ≈ 195 ms on a single scheduler). ### PoC 1. POST `a[a][a]...[a]=1` as `application/x-www-form-urlencoded` to any endpoint of a Plug-based app. Even at the 1 MB urlencoded-parser default the payload carries ~333,000 nesting levels; with the broader `Plug.Parsers` body limit (20 MB default) a single request can carry millions. 2. Launch one such request per scheduler concurrently. Each pins a scheduler for minutes; legitimate traffic stalls once all schedulers are busy. ### Impact A single low-bandwidth sender can render any internet-reachable Plug-based service (most Phoenix and standalone Elixir/Erlang web stacks) unresponsive. No credentials, specific endpoint, or prior knowledge of the application is required. ### References * Introduction commit: https://github.com/elixir-plug/plug/commit/712b875d3442c765d8d37e546ffd5ad9f8afcc55 * Patch commit: https://github.com/elixir-plug/plug/commit/b4aa8a0665ce2726a6d5af44467fb4f59595b107	high	8,7	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N	0,009	0,597	CWE-407	erlang:plug	erlang	0	—	0	1	erlang:plug >= 1.15.0, < 1.15.5; erlang:plug >= 1.16.0, < 1.16.4; erlang:plug >= 1.17.0, < 1.17.2; erlang:plug >= 1.18.0, < 1.18.3; erlang:plug >= 1.19.0, < 1.19.3	https://github.com/elixir-plug/plug/security/advisories/GHSA-j43x-5hjq-rgxf https://nvd.nist.gov/vuln/detail/CVE-2026-54892 https://github.com/elixir-plug/plug/commit/9c5d37c440eaae92869eed7c014c47266744fadb	https://github.com/advisories/GHSA-j43x-5hjq-rgxf	61,41	p2	5
2026-W39	2026-09-24T00:00:00+00:00	GHSA-5JPJ-293F-RHVJ	CVE-2026-62371	2026-09-22T20:37:04Z	2026-09-22T20:37:06Z	KubeEdge: Command Injection in NodeUpgradeJob - RCE on edge nodes via v1alpha2 API	## Impact The KubeEdge NodeUpgradeJob handler constructed the `keadm upgrade edge` command by concatenating the user-controlled `spec.version` and `spec.image` fields into a shell command. An authenticated user with permission to create or update `NodeUpgradeJob` resources through the v1alpha2 API could include shell metacharacters in either field. When the upgrade job was processed, the injected command could be executed on the targeted edge node with the privileges available to the upgrade process. Successful exploitation could result in arbitrary command execution and compromise the confidentiality, integrity, and availability of the affected edge node. ## Patches The fix removes shell-based command construction and invokes `keadm` using a structured argument list through `exec.Command`. The version and image values are passed as separate literal arguments and are no longer interpreted by a command shell. The fixed versions: * KubeEdge v1.23.1 * KubeEdge v1.22.2 * KubeEdge v1.21.2 ## Workarounds Until a patched version is available: * restrict permission to create or update `NodeUpgradeJob` resources to trusted administrators; * do not allow untrusted users or tenants to control the `spec.version` or `spec.image` fields; * avoid using NodeUpgradeJob-based edge upgrades in environments where these fields may be influenced by untrusted users. ## Credits KubeEdge thanks Sang-Hoon Choi ([KoreaSecurity](https://github.com/KoreaSecurity), Sejong University) for responsibly reporting this issue and for coordinating with the KubeEdge maintainers through the security disclosure process.	high	8,8	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	0,009	0,576	CWE-78	go:github.com/kubeedge/kubeedge	go	0	—	0	1	go:github.com/kubeedge/kubeedge >= 1.12.0, < 1.21.2; go:github.com/kubeedge/kubeedge >= 1.22.0, < 1.22.2; go:github.com/kubeedge/kubeedge >= 1.23.0, < 1.23.1	https://github.com/kubeedge/kubeedge/security/advisories/GHSA-5jpj-293f-rhvj https://nvd.nist.gov/vuln/detail/CVE-2026-62371 https://github.com/kubeedge/kubeedge/pull/7028	https://github.com/advisories/GHSA-5jpj-293f-rhvj	61,27	p2	6
2026-W39	2026-09-24T00:00:00+00:00	GHSA-M3C6-2P7H-CFR3	CVE-2026-62182	2026-09-22T20:36:44Z	2026-09-22T20:36:49Z	KubeEdge: ConfigUpdateJob updateFields enables remote shell injection and code execution on edge nodes	## Description KubeEdge ConfigUpdateJob processing was vulnerable to command injection on edge nodes. The `updateFields` values from a ConfigUpdateJob were concatenated into a command string and executed through a system shell. An authenticated user with sufficient permissions to create or update ConfigUpdateJob resources could include shell metacharacters in the supplied configuration fields and cause unintended commands to be executed on targeted edge nodes. ## Impact Successful exploitation could allow an authenticated attacker to execute arbitrary commands on affected edge nodes with the privileges of the KubeEdge process handling the ConfigUpdateJob. The attacker must already have permission to create or modify ConfigUpdateJob resources and target an enrolled edge node. ## Patches The fix removes shell-based command construction and invokes `keadm config-update` using structured command arguments. The complete `--set` value is passed as a single literal argument, preventing shell metacharacters from being interpreted as commands. Fixes are planned for the following maintained releases: * v1.23.1 * v1.22.2 * v1.21.2 ## Workarounds Until a patched release is available: * restrict RBAC permissions for creating or modifying ConfigUpdateJob resources; * allow only trusted administrators to submit configuration update jobs; * avoid using ConfigUpdateJob in environments where its input cannot be fully trusted; * monitor ConfigUpdateJob resources and edge-node process activity for unexpected commands or changes. ## Credits KubeEdge thanks Sang-Hoon Choi ([KoreaSecurity](https://github.com/KoreaSecurity), Sejong University) for responsibly reporting this issue and for coordinating with the KubeEdge maintainers through the security disclosure process.	high	8,8	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	0,009	0,576	CWE-78	go:github.com/kubeedge/kubeedge	go	0	—	0	1	go:github.com/kubeedge/kubeedge >= 1.21.0, < 1.21.2; go:github.com/kubeedge/kubeedge >= 1.22.0, < 1.22.2; go:github.com/kubeedge/kubeedge >= 1.23.0, < 1.23.1	https://github.com/kubeedge/kubeedge/security/advisories/GHSA-m3c6-2p7h-cfr3 https://nvd.nist.gov/vuln/detail/CVE-2026-62182 https://github.com/kubeedge/kubeedge/pull/7028	https://github.com/advisories/GHSA-m3c6-2p7h-cfr3	61,27	p2	7
2026-W39	2026-09-24T00:00:00+00:00	GHSA-6RF4-V2FH-M6P4	CVE-2026-59167	2026-09-24T14:57:55Z	2026-09-24T14:57:55Z	SunEditor: Critical XSS vulnerability - sanitizer bypass	## Summary SUNEDITOR `v2.47.10` appears to allow JavaScript execution through crafted namespaced HTML elements. The sanitization logic does not fully remove executable event-handler attributes from certain custom/namespaced tags. As a result, an attacker may be able to inject HTML content that executes JavaScript when the rendered element is interacted with. This behavior was observed after the changes introduced in this commit: https://github.com/JiHong88/suneditor/commit/9ed405fb0de676e56cd0e6a13c19c103ad5948d3 --- ## Affected Version Confirmed vulnerable: * SUNEDITOR =< `2.47.10` Potentially affected: * Previous versions, if the same sanitization logic is still present --- ## Proof of Concept The following payload preserves an executable event handler: ```html <a:b src="/x"><iframe src=javascript:alert(1)></iframe></a:b> <p><a:b src="/x" onclick="document.body.style.background='red'">click</a:b></p> ``` Simplified PoC: ```html <a:b src="/x" onclick="console.log('XSS:',document.domain,document.cookie)">click</a:b> ``` ```html <p><a:b src="/x" onmouseover="alert('XSS — '+document.domain)">📎 Click here for solutions</a:b></p> ``` --- ## Steps to Reproduce 1. Open SUNEDITOR using version `2.47.10`. 2. Insert the payload above into the editor. 3. Save or render the generated content. 4. Click the generated element. 5. Observe that JavaScript is executed. --- ## Impact This may allow an attacker to inject arbitrary JavaScript into rendered editor content. Depending on how SUNEDITOR is integrated into an application, this could lead to: * Stored XSS * DOM manipulation * Session theft * Credential theft * Account takeover actions performed in the victim’s browser context --- ## Technical Details The issue appears to be related to incomplete handling of namespaced/custom HTML elements such as: ```html <a:b> ``` Event-handler attributes such as `onclick` can remain attached to these crafted elements and execute when interacted with. This suggests that the sanitization process may not consistently normalize and validate custom or namespaced elements before applying attribute filtering. --- ## Suggested Remediation Possible mitigations include: * Normalize DOM elements before sanitization. * Explicitly reject or unwrap unknown/custom/namespaced tags. * Strip all event-handler attributes from all elements, including unknown/custom elements. * Re-validate sanitized output after browser DOM parsing. * Add regression tests for namespaced/custom tag payloads. ---	critical	10	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H	0,004	0,307	CWE-79	npm:suneditor	npm	0	—	0	1	npm:suneditor <= 2.47.10	https://github.com/JiHong88/suneditor/security/advisories/GHSA-6rf4-v2fh-m6p4 https://nvd.nist.gov/vuln/detail/CVE-2026-59167 https://github.com/JiHong88/suneditor/issues/1646	https://github.com/advisories/GHSA-6rf4-v2fh-m6p4	59,2	p2	8
2026-W39	2026-09-24T00:00:00+00:00	GHSA-C8W2-FGVX-VHV4	CVE-2026-61682	2026-09-18T17:15:49Z	2026-09-18T17:15:53Z	kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/warrants and impersonate system:masters in any workspace	# Summary The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own `X-Remote-Group` and `X-Remote-Extra-` headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (`system:masters`) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass. ## Impact In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (`X-Remote-User` / `X-Remote-Group` / `X-Remote-Extra-`). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection. Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could: - assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard; - forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp's delegated-identity mechanism; - forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace; - satisfy per-workspace required-group gating by injecting the required group. The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary. # Patches Fixed in v0.31.4, 0.32.2. The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound `X-Remote-` identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard. Operators should upgrade to a patched release. No configuration changes are required after upgrading. # Workarounds There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping `X-Remote-User`, `X-Remote-Group`, and all `X-Remote-Extra-` headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim. Credit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.	critical	9,9	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H	0,004	0,296	CWE-290,CWE-302,CWE-348	go:github.com/kcp-dev/kcp	go	0	—	0	1	go:github.com/kcp-dev/kcp < 0.31.4; go:github.com/kcp-dev/kcp >= 0.32.0, < 0.32.2	https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4 https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca https://github.com/kcp-dev/kcp/releases/tag/v0.31.4	https://github.com/advisories/GHSA-c8w2-fgvx-vhv4	58,38	p2	9
2026-W39	2026-09-24T00:00:00+00:00	GHSA-VP3W-52V9-Q57F	CVE-2026-77601	2026-09-23T18:51:01Z	2026-09-23T18:51:02Z	OpenC3 COSMOS: Authenticated OS command injection via the `pypi_url` setting	## Summary An authenticated user can execute arbitrary operating system commands on the `openc3-cosmos-cmd-tlm-api` service. The `pypi_url` setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by `/bin/sh`. ## Details The `pypi_url` value is written through the `set_setting` API method, reachable over the JSON-RPC endpoint `POST /openc3-api/api`. In the open-source edition, `authorize` (`openc3/lib/openc3/utilities/authorization.rb`) verifies only that the session token is valid and returns the anonymous user; the `permission:` argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role. During plugin install, `PluginModel.install_phase2` reads the setting and builds the argument string, then runs it through a backtick (`openc3/lib/openc3/models/plugin_model.rb:288`): ```ruby pypi_url = get_setting('pypi_url', scope: scope) # attacker-controlled, no validation pypi_url += '/simple' if pypi_url pip_args = "-i #{pypi_url} -r #{requirements_path}" output = `/openc3/bin/pipinstall #{pip_args}` # Ruby backtick -> /bin/sh -c ``` `get_setting` appends `/simple` to the stored value, and a trailing `#` comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a `requirements.txt` or `pyproject.toml`, which the actor controls because they supply the plugin gem. The sibling installer `openc3/lib/openc3/models/python_package_model.rb:95` performs the same `pipinstall` invocation using an argv array through `ProcessManager.spawn`, which does not involve a shell and is not injectable. `plugin_model.rb:288` is the single site that uses a backtick. ## PoC Confirmed end-to-end over HTTP against a booted `openc3-cosmos-cmd-tlm-api` (puma) with Redis and bucket storage. Every request is authenticated. 1. Obtain a session token: ``` POST /openc3-api/auth/verify {"password":"<password>"} ``` 2. Write the setting (JSON-RPC): ``` POST /openc3-api/api {"jsonrpc":"2.0","method":"set_setting", "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"], "keyword_params":{"scope":"DEFAULT"},"id":1} ``` 3. Upload a plugin gem that contains a `requirements.txt`: ``` POST /openc3-api/plugins (multipart: plugin=@malicious.gem, scope=DEFAULT) ``` 4. Install it: ``` POST /openc3-api/plugins/install/<id> (plugin_hash from step 3, scope=DEFAULT) ``` The injected command executed inside the install process. Contents of the marker file written by the payload: ``` uid=1001(openc3) gid=1001(openc3) groups=1001(openc3) ``` ## Impact Arbitrary OS command execution as the `openc3` user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope. In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it. ## Suggested fix Run `pipinstall` through an argv array instead of a shell, matching `python_package_model.rb:95`: ```ruby pip_argv = ["-i", pypi_url] pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil? pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path] OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope) ``` Optionally also validate `pypi_url` as an `http(s)` URL when the setting is written.	high	8,8	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	0,006	0,453	CWE-78	rubygems:openc3	rubygems	0	—	0	1	rubygems:openc3 >= 5.12.0, <= 7.2.1	https://github.com/OpenC3/cosmos/security/advisories/GHSA-vp3w-52v9-q57f https://github.com/OpenC3/cosmos/pull/3489 https://github.com/OpenC3/cosmos/commit/be70d1d836c83c3b084e768e31a399312d4cbe0b	https://github.com/advisories/GHSA-vp3w-52v9-q57f	57,6	p2	10

Profilé le 25 sept. 2026 à partir de l’instantané 20260925T084236Z-2a314511ec6b

Mesuré

Complétude: 98,5 %
Lignes: 205
Colonnes: 26
Colonnes incomplètes: 4

Colonne	Manquant	Distinctes	Plage	Distribution
snapshot_weekvarchar	0 %	1	—	2026-W39205
fetched_atvarchar	0 %	1	—	2026-09-24T00:00:00+00:00205
ghsa_idvarchar	0 %	204	—	GHSA-26R5-4MM2-PX5C1 GHSA-26VP-8GXG-V4PG1 GHSA-274F-6W77-8QM91
cve_idvarchar	4,9 %	225	—	CVE-2025-538371 CVE-2025-616821 CVE-2025-664551
published_atvarchar	0 %	203	—	2026-09-18T13:11:59Z1 2026-09-18T15:05:13Z1 2026-09-18T16:07:29Z1
updated_atvarchar	0 %	182	—	2026-09-22T20:36:48Z2 2026-09-22T20:37:02Z2 2026-09-22T20:37:06Z2
summaryvarchar	0 %	215	—	9Router has a Login Brute-Force Lockout Bypass via Spoofable X-9r-Real-Ip Header1 9Router has an Authentication Bypass in Public LLM API via Spoofable X-9r-Real-Ip Header1 9router /v1 APIs has unauthenticated access via reverse proxy locality collapse1
descriptionvarchar	0 %	227	—	# Cross-tenant disclosure risk on `DurableTask` bidi RPC This is a low-severity, low-risk cross-tenant data exposure vul1 # Summary 9router enforces a progressive login lockout (5 failed attempts → temporary 30s+ lock) keyed on the client IP.1 # Summary The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any 1
severityvarchar	0 %	4	—	high96 medium87 critical16
cvss_scoredouble	0 %	43	0 → 10médiane 7,1	6 hors du 1er–99e centile
cvss_vectorvarchar	0,98 %	133	—	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H12 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N6
epss_scoredouble	17,1 %	133	0,0008 → 0,0095médiane 0,0035	4 hors du 1er–99e centile
epss_percentiledouble	17,1 %	154	0,0016 → 0,597médiane 0,2646	4 hors du 1er–99e centile
cwesvarchar	0 %	93	—	CWE-7921 CWE-2214 CWE-91810
packagesvarchar	0 %	95	—	pip:mcp-atlassian23 composer:mediawiki/semantic-media-wiki9 go:github.com/klever-io/klever-go6
ecosystemsvarchar	0 %	11	—	go62 pip59 npm35
ml_stackbigint	0 %	2	0 → 1médiane 0	3 hors du 1er–99e centile
ml_categoriesvarchar	0 %	2	—	202 serving3
package_criticalitybigint	0 %	2	0 → 1médiane 0	3 hors du 1er–99e centile
has_fixbigint	0 %	2	0 → 1médiane 1
affected_rangesvarchar	0 %	173	—	pip:mcp-atlassian < 0.22.023 composer:mediawiki/semantic-media-wiki <= 7.1.05 go:github.com/klever-io/klever-go <= 1.7.195
referencesvarchar	0 %	209	—	https://github.com/BitterSecurity/Decepticon/security/advisories/GHSA-g5f9-3xfg-p9mf https://nvd.nist.gov/vuln/detail/CV1 https://github.com/F1bonacc1/process-compose/security/advisories/GHSA-5gm3-9crp-6g3v https://github.com/F1bonacc1/proces1 https://github.com/Graylog2/graylog2-server/security/advisories/GHSA-m9c2-85gv-8xr5 https://nvd.nist.gov/vuln/detail/CVE1
source_urlvarchar	0 %	205	—	https://github.com/advisories/GHSA-26r5-4mm2-px5c1 https://github.com/advisories/GHSA-26vp-8gxg-v4pg1 https://github.com/advisories/GHSA-274f-6w77-8qm91
risk_scoredouble	0 %	166	8,88 → 64,31médiane 41,98	6 hors du 1er–99e centile
risk_tiervarchar	0 %	3	—	p3143 p249 p413
risk_rankbigint	0 %	225	1 → 205médiane 103	6 hors du 1er–99e centile

Dirigez n’importe quel LLM vers le point d’accès des métadonnées — la documentation ci-dessus est aussi lisible par machine (JSON-LD + Croissant).

cURL

curl "https://datazimuts.com/v1/datasets/ghsa_weekly_signals/ghsa_package_advisories_weekly" | jq '{title, rows, columns_count, license}'

Python

import requests

ds = requests.get("https://datazimuts.com/v1/datasets/ghsa_weekly_signals/ghsa_package_advisories_weekly").json()
print(ds["title"], ds["rows"], "rows")

# Sample rows for an LLM context window
for row in ds.get("sample_rows", [])[:5]:
    print(row)

Point d’accès API : https://datazimuts.com/v1/datasets/ghsa_weekly_signals/ghsa_package_advisories_weekly

Astuce : récupérez /llms.txt pour le catalogue complet lisible par machine.

Citer cet instantané

Épinglé à l’instantané 20260925T084236Z-2a314511ec6b et à son empreinte, pour que vos lecteurs obtiennent exactement les données utilisées.

APA

GitHub Security Advisories, weekly digest (agent-curated). (2026). New open-source package security advisories (weekly) [Data set, snapshot 20260925T084236Z-2a314511ec6b, sha256 2a314511ec6b]. Datazimuts. Retrieved 2026-09-25, from https://datazimuts.com/fr/datasets/ghsa_weekly_signals/ghsa_package_advisories_weekly?snapshot=20260925T084236Z-2a314511ec6b

BibTeX

@misc{dz_ghsa_weekly_signals_ghsa_package_advisor_2a314511,
  title        = {{New open-source package security advisories (weekly)}},
  author       = {{GitHub Security Advisories, weekly digest (agent-curated)}},
  year         = {2026},
  publisher    = {Datazimuts},
  howpublished = {\url{https://datazimuts.com/fr/datasets/ghsa_weekly_signals/ghsa_package_advisories_weekly?snapshot=20260925T084236Z-2a314511ec6b}},
  note         = {Snapshot 20260925T084236Z-2a314511ec6b, sha256 2a314511ec6b521095c5ffd9542b6cead4ef33fbb914d4cd7006f331e93687e4; accessed 2026-09-25}
}

Intégrer un tableau ou un graphique

Collez ce code dans n’importe quelle page. L’intégration est épinglée au même instantané, suit le thème clair ou sombre du lecteur et affiche toujours la source, la licence et un lien de retour.

Type

Axe X

Valeur

Agrégat

Thème

HTML

<iframe src="https://datazimuts.com/embed/chart?dataset=ghsa_weekly_signals%2Fghsa_package_advisories_weekly&lang=fr&theme=auto&snapshot=20260925T084236Z-2a314511ec6b&x=updated_at&y=cvss_score&agg=avg" title="New open-source package security advisories (weekly)" width="100%" height="380" style="border:0" loading="lazy"></iframe>

New open-source package security advisories (weekly)

Suivre ce jeu de données

Citer cet instantané

Intégrer un tableau ou un graphique

Utiliser votre propre clé d’IA