标签：#cve

CVE-2026-48854: Unauthenticated Denial of Service via Resource Exhaustion in elixir-grpc Server Vulnerability ID: CVE-2026-48854 CVSS Score: 8.7 Published: 2026-08-25 An allocation of resources without limits or throttling vulnerability exists in the Elixir grpc server component when processing unary requests. Unauthenticated remote attackers can stream unbounded data payloads, bypassing standard timeout mechanisms and exhausting host BEAM VM memory, resulting in an immediate crash of the server node. TL;DR Unauthenticated remote attackers can crash the Elixir gRPC server (BEAM VM) by sending unbounded unary requests or using a slow-trickle stream, bypassing default timeouts and causing out-of-memory crashes. ⚠️ Exploit Status: POC Technical Details CWE ID : CWE-770 Attack Vector : Network CVSS Score : 8.7 (High) EPSS Score : 0.00344 (Percentile: 26.92%) Impact : Denial of Service (BEAM VM Crash) Exploit Status : PoC Level KEV Status : Not Listed Affected Systems elixir-grpc/grpc server-side component grpc : >= 0.3.1, < 1.0.0 (Fixed in: 1.0.0 ) Code Analysis Commit: 49e18c3 Fix memory leak and infinite timeout in Cowboy adapter by implementing max_body_size limit and resolving chunk timeouts correctly. @@ -30,10 +30,22 @@ \n+ @default_max_body_size 4 * 1024 * 1024\n...\n- {:ok, data, req} -> {:ok, body <> data, req}\n- {:more, data, req} -> read_full_body(req, body <> data, timer)\n+ {:ok, data, req} ->\n+ total = body <> data\n+ if byte_size(total) > max_bytes do\n+ throw({:body_too_large, byte_size(total)})\n+ else\n+ {:ok, total, req}\n+ end Exploit Details GitHub Security Advisory : Official PoC details and technical validation parameters. Mitigation Strategies Upgrade to elixir-grpc client and server packages version 1.0.0 or higher. Restrict the maximum body size at the reverse proxy or ingress controller layer to prevent large payloads from reaching the backend Cowboy server. Deploy WAF rules to detect and rate-limit HTTP/2 connections with missing grpc-timeo

China's intelligent driving is moving fast from highway Navigate on Autopilot (NOA) into the far harder world of urban NOA. The first leap moved hands-free driving out of the closed expressway and into real city streets. The second leap, the one now underway, is rewriting how the car actually thinks. 1. The Rules Era: An "Exam-Cramming" Trap for City NOA Highway NOA was relatively simple to crack. The road is closed, the geometry is consistent, the actors are mostly cars, and a mature rule-based stack can deliver a comfortable product. Urban NOA is a different beast. The system has to handle traffic lights, unprotected turns, pedestrians, e-bikes, food-delivery scooters running red lights, and a hundred flavors of "I-don't-care-about-the-rules" intersection behavior. The complexity grows exponentially. The earliest urban NOA architectures followed one mantra: cover every possible scenario with hand-written rules . Engineers enumerated traffic situations and wrote thousands of if-then-else statements: when to start moving after a light turns green, how much to slow when cut off, how to plan a trajectory for an unprotected left turn. On the highway this approach can pass a test. In the city it falls apart for a single structural reason. China's urban road users, almost by definition, do not follow the rules. Electric scooters drive the wrong way. Pedestrians cross mid-block. Food-delivery riders weave between cars. Drivers in congested intersections play chicken in the kind of "zipper merge" etiquette nobody teaches. These are the long-tail scenarios that no rule library can fully enumerate. As one early test team admitted about their own city NOA: "It feels like exam cramming — it scores beautifully on the routes we pre-mapped, and the moment it hits an unrecorded scenario, it hesitates, behaves awkwardly, and then asks the driver to take over." That "偏科" (one-trick) experience is precisely why urban NOA penetration in China only reached about 15.1% in 2025 , and rem

TL;DR What: Gammu SMSD — the daemon behind a huge number of SMS gateways, alerting rigs and 2FA senders — runs an operator-configured hook every time a text arrives. With the Files backend and RunOnReceive enabled, the SMS sender ID was escaped for use as a filename but not for the shell , and then appended to a /bin/sh -c command line. A sender ID containing shell metacharacters executed arbitrary commands as the gammu-smsd user. Impact: Remote, unauthenticated code execution triggered by sending a text message. Commands run with the daemon's privileges. Missing neutralization of special elements in an OS command (CWE-78). Fixed in: Gammu 1.43.3 . Advisory GHSA-9vjj-v46c-c5qf , published 25 July 2026, rated High (8.1) , credited to me as reporter. CVE requested, pending GitHub assignment. Why you should care Most command-injection bugs need the attacker to already be talking to your HTTP API. This one needs a phone number. Gammu SMSD sits on the receiving end of a modem or GSM dongle. Hospitals use it for on-call paging, monitoring systems use it for SMS alerts, and plenty of small shops use it as the cheap half of a 2FA setup. A very common configuration is: store incoming messages as files (the Files backend ), and run a script whenever one arrives ( RunOnReceive ) — to forward it, log it, or trigger something. The input to that script comes from the outside world over the cellular network. The sender doesn't authenticate to anything. And on many networks the sender ID is an arbitrary alphanumeric string , not a phone number — that's how banks send texts that say "HSBC" instead of a number. Alphanumeric sender IDs are attacker-controllable, and they can carry the exact characters a shell treats as syntax. That is the whole bug: a value from a text message reaches /bin/sh . The setup Gammu SMSD's Files backend writes each received message to a file whose name includes the sender. To keep that filename legal, it runs the sender ID through an escaping function first

GitPython ships a guard against dangerous git options. If your code builds a clone command out of anything that arrived from outside, the library will not let --upload-pack or --config through by default, because both of them execute an arbitrary command. The guard is on out of the box and turns off only with an explicit allow_unsafe_options=True . I handed it --upload-pack=/srv/lab/helper.sh . It refused. I handed it the same thing written differently, -u/srv/lab/helper.sh , and it let it through. The script ran. This is CVE-2026-67324, published on 1 August 2026, scored 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0. Those numbers still come from the CNA that filed it: NVD has not run its own analysis yet, the record sits in status Received, so the score may move. Version 3.1.50 is vulnerable, 3.1.51 is fixed. Below, step by step: the lab, both attempts with real output, the code of the check and why it missed, and what the attack looks like from the outside. Plus the part I find more interesting than the hole itself. This is the third bypass of the same barrier within one year, and all three share a root cause. Why this deserves your attention Almost nobody installs GitPython on purpose. It gets 254 million downloads a month from PyPI against five thousand stars on GitHub, and a two-order gap like that means one thing: it arrives as a passenger. With MLflow, with DVC, with bandit, with semgrep, with half the homegrown scripts that touch repositories in CI. Let me draw the boundary right away, so nobody panics for nothing. Having it installed is harmless on its own. The hole fires only when two conditions hold at the same time: your code calls Repo.clone_from(..., multi_options=[...]) , something an outsider influences ends up inside multi_options . The second one happens more often than it sounds. A repository URL from a web form, build parameters from a config another team edits, a field in a CI job, arguments from a webhook. And if you are leaning on allow_unsafe_options=

Everyone's telling you the same thing right now: update WordPress. Which is, fine, yes, obviously but that's not enough. Patching closes the hole. What is someone is already In your system? So let's actually walk through this properly what to do right now, what to do if you can't patch immediately, and what to do if you think you were already hit. Need more context? I wrote a summarising one here. wp2shell: The Bug That Turned an Empty WordPress Install Into a Shell Aditya Pidurkar Aditya Pidurkar Aditya Pidurkar Follow Jul 22 wp2shell: The Bug That Turned an Empty WordPress Install Into a Shell # wordpress # wp2shell # cybersecurity # cve Add Comment 4 min read S1: Stop assuming you're patched. Go check. WordPress flipped on forced automatic background updates for this one because of how serious it is. That's great, except "forced" doesn't mean "guaranteed", VERIFY IT. Go look at your actual running version right now: In the dashboard: wp-admin > Updates Via WP-CLI, if you have shell access: wp core version You want to see 7.0.2 if you're on the 7.0 line, or 6.9.5 if you're on 6.9. If you see anything else — 6.9.0 through 6.9.4, or 7.0.0/7.0.1 — you're still exposed. Update it now!! Come back when done. A few situations where the forced update quietly doesn't happen, in what I read on internet: Managed hosting environments where the host controls the update pipeline and hasn't pushed it yet Sites with a "disable auto-updates" plugin installed months ago for stability reasons and never revisited wp-config.php with WP_AUTO_UPDATE_CORE explicitly set to false Staging or dev environments nobody thinks of as "production" but that are still internet-facing If any of that describes you, don't wait on the automation. Update manually. S2: If you genuinely can't update right now, here's your stopgap aybe you're facing a compatibility issue, a change freeze, or a custom plugin that isn't ready yet. It happens. If you need a little more time before applying the real fix, here'

Every open-source CVE backlog has that one line item you keep sliding into next quarter. The library is a couple of majors behind, the upgrade breaks four services, and the fix upstream ships against a version you cannot ride to. So you file the ticket again. (Everyone's doing great, thanks for asking.) On June 30, Aikido Security said it had acquired Root, whose whole pitch is to make that ticket go away by another route: patch the vulnerability directly into the version already resolved by your build, and skip the upgrade entirely. Per The New Stack, the deal is worth $70 million, and Root's patching technology gets folded into a new Aikido product. Let me phrase what has just moved as plainly as I can. A vendor now edits open-source packages on your behalf and hands you back a version string upstream never shipped. If that sentence made you flinch, hold the flinch. It is doing useful work. The problem this is actually solving The dirty secret of dependency remediation is that a lot of "known" CVEs sit unfixed because remediating them means a version bump that carries breaking changes. You do not get a security patch for the 2.x line, you get a "fixed in 4.0" release note and a laugh track. Backporting the fix is the right operational move: keep the API surface, change only the vulnerable bytes. Linux distributions have done exactly this for decades. The reason your app team is not doing it too is that nobody has the muscle to maintain a patched fork of every transitive dependency in a lockfile. If Aikido now makes that muscle available to the average CI/CD owner, teams get a lever they simply did not have. That is the honest upside. Own it. Who is signing what, exactly Here is the part I care about, which is trust. When your build resolves a package by name and version, you rely on a chain: the registry answers, the digest matches what upstream published, the SBOM you generate downstream still refers back to that same identity. A backported build breaks that chai