Rapid7 Named Among Notable Vendors in Forrester MDR Landscape: Why the Future is Exposure-informed, Preemptive MDR

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/dr-forrester-mdr-landscape-notable-vendor-preemptive

The managed detection and response (MDR) market has reached a turning point. We’ve gone beyond the baseline of 24/7 monitoring focusing on the speed of detection and moved to a world with a convergence of exposure management and response to deliver measurable, outcome-based defenses of a larger, AI-driven attack surface.

For anyone evaluating MDR right now, the Managed Detection and Response Services Landscape, Q3 2026 report by Forrester is a useful map that lays out where the market is heading. This is a market that has moved beyond “do you cover my telemetry?” to “Can a provider connect and prove that its activity is tied to real reduction in risk?”. 

Rapid7 was named among the notable providers in this Forrester MDR Landscape. Being included matters to us, but the more interesting story is in what Forrester says about the market itself.

Detection and exposure are becoming one service

One of the report’s clearest signals is directional: Forrester writes that “MDR services will converge with exposure and posture improvement.”

That convergence is the whole basis of Rapid7 MDR and our Command Platform strategy. Most MDR services react after an attacker has already broken in. Rapid7 designed its service to anticipate where attackers are likely to succeed and disrupt them earlier. We combine exposure context, detection, and response into a single operational loop, where vulnerability findings and asset risk scoring flow directly into alerts and investigations. This means analysts can cut noise and focus response on the exposures most likely to cause business impact. It’s what we mean by exposure-informed, Preemptive MDR: The same context that tells you where you’re weak is the context that sharpens how you detect and respond.

For buyers, the practical implication is that old procurement habits are changing. Buyers used to invest in detection from one vendor, exposure management from another, and then hope the two solutions would seamlessly talk to each other. That approach is now turning into a liability.

The market will reward providers that connect these additions to measurable risk reduction rather than bolting on loosely joined SKUs. That’s a bar customers should hold every provider to, including Rapid7.

“Make providers prove the investigation, rather than narrate the dashboard”

The second theme is about accountability. In its guidance on working with providers, Forrester is blunt: Buyers should “make providers prove the investigation, rather than narrate the dashboard.” A slick activity feed is not evidence that anyone reached the right conclusion. Buyers should ask to see the reasoning behind a disposition, the actions taken, and the controls that keep automation from making unsafe decisions.

This is a healthy pressure on the whole market, and it’s a test we welcome. Rapid7 MDR is delivered on Rapid7’s own SIEM, which gives customers a direct window into our SOC, including validated threats, the response actions taken, where AI accelerated the work, and where a human analyst stepped in and why. Every action is logged, explainable, and auditable. As agentic AI takes on more of the investigation workload, that transparency becomes the difference between a service you trust and a black box you hope is working. Our approach is deliberately human-led and AI-enhanced: AI scales triage and investigation across large volumes of telemetry, while analysts stay responsible for validation and response decisions.

Accountability also shows up in commercial terms. Rapid7 MDR includes unlimited incident response, so the team stays engaged until an incident is fully remediated rather than stopping when a clock runs out, and gives a concrete answer to the “who owns the outcome?” question.

What to do with the report

If you’re evaluating MDR, and have access to Forrester, the report is a strong prompt to rewrite your evaluation criteria. A few questions worth taking into any provider conversation:

  • Ask how exposure context actually enters investigations. Is it a legitimate input to detection and prioritization, or a separate dashboard? 

  • Ask to see a real, redacted case file rather than a metrics summary. Then probe how the provider handles uncertainty and model failure. 

  • Clarify the place where accountability sits when a response action carries risk, and get a clear answer on how far the provider remains engaged during an incident. 

These are the same standards we hold ourselves to, and they map to how we’ve built our MDR service. If you want to go deeper, our MDR Buyer’s Guide walks through what to look for in a partner, and you can compare Rapid7 MDR against other providers or talk to our SOC team directly.

The MDR market is one in which detection, exposure, and response stop being separate purchases and start being one accountable outcome. That’s the service we set out to build, and now is a good moment for every security leader to ask whether their current provider is heading the same way.

Source: Forrester, The Managed Detection And Response Services Landscape, Q3 2026, Jeff Pollard with Joseph Blankenship, Emily Doherty, and Michael Belden, September 1, 2026. Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .

Security updates for Monday

Post Syndicated from jzb original https://lwn.net/Articles/1094211/

Security updates have been issued by AlmaLinux (389-ds-base, apr-util, coreutils, freerdp, git-lfs, glib2, gstreamer1-plugins-base, kernel, libkcapi, nginx, nodejs:22, nodejs:24, osbuild-composer, perl-YAML-Syck, postgresql16-postgis, ruby, ruby4.0, ruby:3.3, and vim), Debian (jbig2dec, kamailio, nginx, spip, and xorg-server), Fedora (baresip, bind, bluez, bubblewrap, chirp, chromium, cockpit, composer, corosync, darktable, dokuwiki, elixir, exiv2, expat, firefox, freerdp, freerdp2, gdk-pixbuf2, gegl04, golang-x-perf, grpcurl, kernel, kernel-headers, libevent, libmongocrypt, libpcap, libre, libsoup3, memcached, mingw-expat, mingw-openexr, mongo-c-driver, mrtg, nagios-plugins, nsd, nss, openssl, openvpn, PackageKit, pdns-recursor, perl-Net-OAuth, perl-XML-Bare, php-pecl-mongodb2, python-asteval, python-pip, rclone, rest, rust-hickory-net, rust-hickory-proto, rust-hickory-resolver, rust-ppmd-rust, rust-webbrowser, srt, syncthing, tar, tkimg, and valkey), Gentoo (Chromium, Google Chrome, Microsoft Edge, Opera, Vivaldi and Ruby), Mageia (bind, ffmpeg, glibc, java-17-openjdk, java-21-openjdk, librabbitmq, perl-Catalyst-Plugin-Static-Simple, perl-Imager, tor, and xz), Oracle (389-ds:1.4, ansible-core, apr-util, coreutils, freerdp, git-lfs, glib2, gstreamer1-plugins-base, gzip, httpd:2.4, image-builder, java-21-openjdk, kernel, mrtg, nginx, osbuild-composer, perl-DBI, postgresql16-postgis, python-lxml, python3.12-lxml, redis:6, and vim), SUSE (389-ds, ansible-core, ansible-creator, azure-storage-azcopy, cargo-audit, chromedriver, chromium, clamav, containerized-data-importer1.65, containerized-data-importer1.66, curl, dracut, ffmpeg-4, google-guest-agent, google-osconfig-agent, helm, java-1_8_0-ibm, jupyter-nbconvert, kernel, libpng16, libusb-1_0, libvirt, multipath-tools, NetworkManager, opensc, openssl-3, perl-Authen-SASL, perl-HTML-FormHandler, perl-Mojolicious, perl-Protocol-HTTP2, python-jwcrypto, python-sqlparse, python-tornado6, python313-geopy, python313-modelscope, python313-modelscope-hub, python313-pypdf, python315, rpcbind, sshamble, strongswan, tomcat, ucode-intel, and wget), and Ubuntu (civetweb, ffmpeg, and urwid).

Launching Astro Pi 2026/27: Code your way to the International Space Station

Post Syndicated from Fergus Kirkpatrick original https://www.raspberrypi.org/blog/launching-astro-pi-2026-27-code-your-way-to-the-international-space-station/

Strap yourselves in for an out-of-this-world journey! The European Astro Pi Challenge 2026/27 officially launches today, 14 September 2026!

Young people across Europe and Canada are invited to participate in two fun coding missions, offering them the amazing opportunity to run their programs on the Astro Pi computers aboard the International Space Station (ISS). Every successful team will receive official certificates complete with runtime details and orbital coordinates, along with their very own space data and image sets to download and keep.

The European Astro Pi Challenge is an ESA Education project run in collaboration with the Raspberry Pi Foundation, and implemented by ESEROs at a national level. It gives young people the chance to learn how to code and conduct real space science in orbit.

Which mission will your teams launch this year?

Pixel art images from the Mission Zero project guide for this year’s Astro Pi challenge.
New Mission Zero code examples

Mission Zero: Art in orbit

Send your art to orbit and create colorful pixel art with code! Mission Zero is a beginner-friendly Python activity, perfect for young people aged 9 to 16 with no prior coding experience.

Participants use our web-based code editor to set image colors and capture live light readings to adapt their artwork. In our step-by-step project guide, you’ll find a selection of starter examples to modify and make your own, all chosen directly from entries from the 2025/26 season.

Because so many teams love bringing their artwork to life, Mission Control has included step-by-step worked code examples in our project guide: one that creates a static image, and another that outputs a two-frame animation. Your team can modify the colours, add extra frames, or design an entirely original piece. We can’t wait to see what participants create.

Photos of Earth’s surface captured by Astro Pi cameras on board the ISS.
Earth observation images captured by Mission Space Lab teams

Mission Space Lab: Real orbital science

Calling all aspiring space scientists! Mission Space Lab gives young people aged 12 to 19 the chance to capture real sensor data and Earth observation images while the ISS orbits 400km above us.

Working in teams of between two and six young people, participants write a Python program to log sensor or camera data to explore life on Earth or orbital mechanics. Teams can design an entirely original space science project or use our ready-made guides to analyse vegetation using NDVI imaging, or calculate the speed of the ISS. Every eligible program is guaranteed a ten-minute flight slot on the ISS.

This year, you’ll find a template for a basic data capture submission in the Mission Space Lab Creator Guide. It provides a great starting point for teams to predict the output of their program, test their logic, and customise their code. What will your team choose to investigate?

An astronaut operating the Astro Pi computer inside the International Space Station.
Astro Pi computers aboard the ISS

Meet our ambassador

We are excited to announce that ESA astronaut Thomas Pesquet will be the ambassador for the European Astro Pi Challenge this year. Having worked aboard the ISS, Thomas knows how important it is to conduct scientific experiments in space. Plus, Thomas is no stranger to the European Astro Pi Challenge. In fact, he has been our ambassador twice before, during the 2016/2017 and 2020/2021 editions. He is currently preparing for his next mission, having been selected to command a private astronaut mission, planned for 2027.

An astronaut inside the International Space Station.
Credit: ESA/NASA

Get in touch with Mission Control

The Astro Pi Mission Control team is here to support you every step of the way. Visit our website to learn how to book a support call with our team, or reach out to us directly at [email protected].

We’ll also be hosting interactive support sessions and livestreams for both missions throughout the year. Make sure you stay connected by signing up for our official newsletter.

In the meantime, look to the stars and see how far your young people can reach!

The post Launching Astro Pi 2026/27: Code your way to the International Space Station appeared first on Raspberry Pi Foundation.

More than 9,000 patches total in the seven stable kernels for Monday

Post Syndicated from jzb original https://lwn.net/Articles/1093985/

Greg Kroah-Hartman has announced the 7.2.6,
6.18.52, 6.12.110, 6.6.157, 6.1.188,
5.15.221, 5.10.270 stable kernels.

According to
Kroah-Hartman
, this batch may set a record for the number of patches with
more than 9,000 in total between them. There are more than 1,800
patches
in 7.2.6 alone. Users of these kernels are, of course, advised to
upgrade.

Microsoft’s Patching

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/09/microsofts-patching.html

Once a month, Microsoft pushes a security update to all Windows users. Tomorrow’s is a new record:

Microsoft’s patch for September is a doozy, with a record number of roughly 972 vulnerabilities fixed and 112 of them meeting the high critical-severity threshold.

It was only two months ago that Microsoft patched a then-record 570 vulnerabilities. Then, last month, Microsoft patched some 620 of them. Google and other companies have also published record numbers of vulnerabilities in recent months. Two weeks ago, OpenAI, Anthropic, Amazon Web Services, Google, Microsoft, and 100 companies and organizations published an open letter warning of a narrowing window for patching vulnerabilities ahead of an expected tsunami of AI-enabled attacks that actively exploit them first. The industry is taking the threat seriously by pumping out unprecedented numbers of patches in their software.

This is the result of AI-powered vulnerability finding, and a good example of AI helping the defenders more than the attackers.

What will be interesting to watch is how the number of vulnerabilities changes over the next few months. My prediction is that it will continue to increase as the AIs get better at finding software vulnerabilities, and then decrease as they run out of vulnerabilities to find. How high the number gets, how fast the trend reverses, and how quickly it declines after that are all unknown.

And Microsoft is right: The window to patch has shrunk to “immediately.” AIs are also good at reverse-engineering exploits from patches, which means that these vulnerabilities will be weaponized as soon as the update is published.

CVE-2026-85706: Critical GitLab Path Traversal Exploited in the Wild

Post Syndicated from Rapid7 original https://www.rapid7.com/blog/post/etr-cve-2026-85706-critical-gitlab-path-traversal-exploited-in-the-wild

Overview

On September 10, 2026, GitLab published a critical patch release for GitLab Community Edition (CE) and Enterprise Edition (EE). The release addresses CVE-2026-85706, a critical path traversal vulnerability (CWE-22) in the repository commits API with a CVSSv3.1 score of 10.0. According to GitLab, improper path confinement and missing authentication enforcement could allow an unauthenticated user to read arbitrary files from an affected GitLab server under certain conditions.

On September 11, 2026, CVE-2026-85706 was added to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation. CISA set a remediation due date of September 14, 2026, for affected Federal Civilian Executive Branch agencies and marked the vulnerability as subject to forensic triage requirements under Binding Operational Directive 26-04.

Organizations running affected self-managed GitLab instances should remediate CVE-2026-85706 on an emergency basis, outside of normal patch cycles.

Mitigation guidance

A vendor-supplied update is available to remediate CVE-2026-85706. Organizations running affected self-managed GitLab CE or EE instances should upgrade to a fixed version immediately.

Affected GitLab CE/EE versions

Fixed version

All versions from 18.7 before 19.1.8

19.1.8

All versions from 19.2 before 19.2.6

19.2.6

All versions from 19.3 before 19.3.2

19.3.2

GitLab.com is already running a patched version, and GitLab Dedicated customers do not need to take action. Per GitLab, all self-managed deployment types are affected, including Omnibus, source code, and Helm chart deployments.

The updates include database migrations. Single-node installations will experience downtime while the migrations run; multi-node deployments can use GitLab’s zero-downtime upgrade procedure. Of the fixed releases, only 19.3.2 includes post-deployment migrations.

The patch release also addresses 17 other vulnerabilities. These include CVE-2026-87719, a critical insecure deserialization vulnerability (CWE-502) in GitLab EE with a CVSSv3.1 score of 9.9. GitLab states that, under certain conditions, an authenticated user with Duo Chat access could obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument. At the time of publication, only CVE-2026-85706 is known to be exploited in the wild.

Given the confirmed exploitation, Rapid7 strongly recommends looking for signs of compromise even after the update has been applied. Organizations subject to CISA’s BOD 26-04 should also follow the forensic triage requirements associated with the KEV entry.

For the latest mitigation guidance, please refer to the vendor’s security advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-85706 with a vulnerability check available in the September 15 content release.

Updates

  • September 14, 2026: Initial publication.

Must be surreal

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/must-be-surreal/

Must be surreal to live history all over
repeating the same lies of self-defense,
superiority, destiny and final solution
watching passively as everyone –
yourself included – prays, votes, kills,
burns and rebuilds atop graves.

Must be heartbreaking to watch
your bloodline relive what you endured
now from the perpetrator’s desk
history forgotten, repeated, rebranded
uttering those exact excuses and hate
following through as orders are followed.

Must be difficult to face the tape rolling
once ashes and truth settle alike,
to explain once more, eighty years later,
to insist common folk didn’t know,
only sought safety and promised destiny,
to feel the shame once those lies crumble.

Must be painful for the witness and learned
to watch events unfold and reconstruct
what was once labeled as „never again“
knowing that in eighty more years
the bloodline of those who now slay
will emerge from the shame and lead yet again.

Must be terrifying to entertain the thought
that what remains of a charred people –
scattered across, but not at home –
will rise to hunt the monsters down
one by one, as decades past,
to end, to seek justice, to avenge.

Must be certain some labels will be named:
terror, and stench of decaying foe
or truth seekers and retribution
for a humanity failing yet again.

Must be up to the scribes or those
who will still utter „never again“
and still fail to know how or what,
yet dream of safety and promised destiny.

The collective thoughts of the interwebz