Africa’s Cybersecurity Challenge Is Bigger Than Access to Technology

Post Syndicated from Gopan Sivasankaran original https://www.rapid7.com/blog/post/c-starlink-distribution-partnership-africa

Gopan Sivasankaran is Rapid7’s Regional Director, Middle East & Africa.

Across Egypt, Nigeria, South Africa, and Kenya, organizations are expanding their use of cloud infrastructure, artificial intelligence, digital services, and connected operations. But more technology does not automatically create stronger security operations; many security teams are not short on data, but rather on time, context, and specialist capacity.

As environments expand, the challenge is no longer finding another security product. It is turning existing technology and new investments into clearer risk decisions, faster investigations, and more consistent response, which requires more than software.

Rapid7 and StarLink: From access to operational capability

Africa has been an important region for Rapid7 for many years, and we’re proud of the role we’ve played in protecting organizations across the continent. We see significant opportunity ahead and remain committed to investing in our presence, partner ecosystem, and customer relationships across the region.

That continued investment is why Rapid7 is expanding its partnership with StarLink across Egypt, Nigeria, South Africa, and Kenya.

Security teams are often managing data across endpoints, cloud environments, identities, and third-party systems. Adding another disconnected tool can increase workload rather than reduce it. Modern security operations require a more connected approach. Exposure data should help teams understand where risk exists. Detection should identify active threats. Response and automation should help teams act before an issue becomes a larger business incident.

But even a well-designed platform needs skilled partners who can help customers deploy it, integrate it, and adapt it to local operational needs.

Why regional partner capability matters

Cybersecurity maturity varies by country, industry, and organization. A bank in South Africa, a digital services provider in Kenya, a public-sector organization in Egypt, and an enterprise in Nigeria may share some security challenges, but they do not operate in identical environments. Partners provide the bridge between global technology and local customer reality.

Through this collaboration, Rapid7 and StarLink intend to give resellers, systems integrators, and managed security service providers access to technical enablement, solution expertise, and joint go-to-market support. The goal is to help partners build sustainable security practices, not simply complete individual product transactions.

Connecting exposure, detection, and response

Rapid7’s security operations approach brings exposure management, threat detection and response, managed services, and automation together. This can help teams connect two questions that are too often handled separately:

  • Where are we most exposed?

  • Where are attackers active now?

When partners can help customers answer both questions using shared security context, they can support more informed prioritization, faster investigation, and clearer remediation decisions.

Looking ahead

Africa’s digital growth will continue to create new security demands. Meeting them will require technology, but also skills, services, local understanding, and long-term collaboration. Rapid7 and StarLink are working together to help build that capability across the region.

Ready to build your security practice with Rapid7? Contact your Rapid7 or StarLink representative for upcoming training, technical enablement, and joint go-to-market opportunities, or explore the Rapid7 PACT Partner Program.

The 7.2 kernel has been released

Post Syndicated from corbet original https://lwn.net/Articles/1088991/

The 7.2 kernel has been released.
Linus said:

Well, this last week of the release was – once again – bigger than
I would have wished for, but hey, with the whole “new normal”
thing, if I delayed releases for that reason we’d probably never
have a release at all.

Significant features in this release include
common
attributes support in the bpf() system call,
cache-aware load balancing for the CPU
scheduler,
large-folio support in the Btrfs filesystem,
further swap subsystem improvements,
improvements to the Landlock security module,
support for block devices with inline encryption hardware via the dm-inlinecrypt
device-mapper target, and much more.
See the LWN merge window summaries
(part 1, part 2) and the KernelNewbies 7.2 page
for more information.

Age Verification Is A Bad Way To Solve The Problem of Children on Social Networks. What’s The Alternative?

Post Syndicated from Bozho original https://techblog.bozho.net/age-verification-is-a-bad-way-to-solve-the-problem-of-children-on-social-networks-whats-the-alternative/

Age verification for using social networks is an idea that is gaining traction in multiple countries around the world – it started in Australia, then the UK, and currently sees increasing support in France and other EU countries, as well as in the European Commission. The idea sounds simple – “social networks are proven to be detrimental to children’s mental health, and so they must not be allowed to use it. The way to do it is to add an age check before registration, so that only adults can use the service”.

While simple to formulate, it’s much more difficult to implement, if not impossible.

First, let’s be clear that I agree 100% that social networks, with their addictive design, their lack of content curation and mediocre attempts to protect children, are bad for minors. And policy makers, such as myself, as a member of parliament of an EU country, need to address that.

But age verification is hardly the right solution, as it’s problematic in many ways which I’ll try to describe here.

  1. Privacy – the obvious, but rarely state fact, is that age verification is for every online user, not just for children. In order to limit children, you have to check everyone, and let only people about 18 (or 16) to use a given service. That poses serious privacy concerns and so policy makers are trying to find privacy-preserving solutions that don’t require users to show their face and identity document on every registration.

    “Age tokens” and “age attestations” have been discussed and even implemented. The EU even created a privacy-preserving app, with zero-knowledge prove, that proves the someone is above 18 without them disclosing any identity data (even their age) to the relying party (e.g. a social network). This, however, has problems with circumvention, which I’ll address in the 2nd point. The problem is that fully privacy-preserving solutions are going to be circumvented. If privacy is compromised – i.e. if the solution leaks identifiable information to service providers, age verification becomes “mandatory digital identity for everyone”. I’m a proponent for digital identity for a long time, but strictly optional and mostly for government services, no as a permission to use the internet.

    The French law was this weak blocked by the French Constitutional court based on privacy issues. And UK age verification examples have shown some disasters – e.g. one age verification company was found vulnerable and it became obvious that they don’t just check your age – they check you against multiple registers and lists, including for terrorism – which is logical if you want to use every opportunity to reduce risks, but that’s not “on the brochure”.

  2. Circumvention – even if age verification is properly implemented, it can easily be circumvented by good old VPNs. However, as we know, VPNs are a gateway to a darker internet, where other safeguards and protections are also off. The reality in Australia and the UK is such that VPN usage spiked and many children continue to use social networks – so while governments created a privacy nightmare, they didn’t achieve the initial goal.

    But privacy-preserving age verification is possible and that’s why we have to address this very seriously. The EU has made a well-meaning attempt to design and implement a proper zero-knowledge proof of age. It’s a great tool, with proper cryptography, complex-yet-elegant. It has “just” one problem – it didn’t account for the actual “threat actor” in this scenario – the user, who would try many things to circumvent the age limitation. As security consultant Paul Moore has brilliantly shown, you don’t have to compromise the age verification app in order to circumvent the flow – by a simple relay attack, where you just present someone else’s verified age credentials in order to use a service. The proof of concept was implemented as a chrome extension which relays age checks to 3rd party service, backed by an over-18 person’s device, which sends the proof to the service. That way a single adult can verify the accounts of all minors, and because of the necessary privacy guarantees, the relying party (the social network) won’t even know.

    This is very likely to happen, which “age verification as a service” providers pop-up to help minors get into social networks. What’s worse – some of these providers may collect children’s personal data, including phone number or social network account ID, in order to provide them with the much coveted proof of age. That data, purposefully or after an inevitable data breach, may be used by sex predators to target children. There are completely realistic nightmare scenarios, born from the good intention to limit the negative effects of social networks.

    Even in a school context, a single over-18 (or over-16) student can lend their age verification app to help younger children register profiles. What are policy makers going to do then? Issue administrative fines for sharing age tokens/attestations? Criminilize it? It’s obviously the wrong path.

    There is one option that may improve this approach, but doesn’t fix it – binding the age attestation to a device ID, so that one device (physical or virtual) can have only one account. That, however, breaks the privacy guarantees – yes, it’s not a personal identifier, but a device identifier, but nevertheless, it allows linking and leaking. And may still be circumvented – with per-request virtual device creation, which would require rate-limiting of attribute providers functionality to attest age. So, broken privacy guarantees and further technical complication that are also likely to be circumvented when someone thinks about it for more than 2 days.

    There seems to be a fundamental mismatch between “perfect privacy” and “age verification” (as shown by Paul Moore as well), because if you achieve sufficient privacy guarnantees (like the one in the EU app), a relay attack makes the whole approach useless. And if you ignore or weaken privacy, the whole measure becomes much more problematic.

  3. Adoption by social networks – every relying party (social network or other age-restricted service) has to implement the age verification flow. Some may get it wrong, have bugs. But some may decide not to implement it. What’s the penalty for that – huge fines and ultimately – a total ban from the EU? For larger platforms that may not be a good option commercially, but for others, especially non-profits, niche players, etc, it may be the preferred option. This approach also limits EU’s and EU countries flexibility in determining who has to comply – it’s not just a monthly-updated list of age-restricted services; it’s a complicated compliance process, implementing custom, location-based registration and confirmation flows, compliance analysis, legal documents, whatnot.

Obviously, “showing your ID card to the cashier” is not as trivial in the digital world as it is in the physical world. That already leads to a backlach, and policy makers should be aware of those limitations.

The title of this post ends with a question – what’s the alternative? My proposal has two components:

  1. Limit the addictive features of social networks and present age-appropriate versions, with age-restricted content – yes, that’s harder for social networks, and it will lead to a drop in monetization. Because such a proposal will likely focus not only on children, but on adults as well – addictive feeds and endless reels are problematic for adult users as well. And policy makers will have to answer why they are not protecting everyone, if they have the legal instrument to do it?
  2. More heavy reliance on parental control apps – parental control apps are rudimentary nowadays, and maybe that’s for a reason. They are not popular, unintuitive, buggy. But they can be regulated and fixed. What’s more – they can have government-mandated blacklists for children, based on age. For example, a state agency for children protection can publish a blacklist of apps and domains that the parental control apps have to import automatically. Legislators can also require these apps to be pre-installed on every phone sold in their country. This would still leave parents in control – if they trust their children to be responsible, they can fine-tune the settings.

    Certain apps can be banned for under-14, others for under-16 and others – for under-18. Governments would be much better control over the exact services they deem risky for children, without the need for any changes on the service’s side. Or, if an app vendor wants to have it whitelisted, they may have to implement children-friendly versions.

    Going further, this may eventually lead to platform-level parental control APIs, so that each app can read parental control settings, and on the other hand export parental control configuration options to be used in the parental control app.

This approach is much better from political point of view – it’s not that government that decides – it’s the parent, but with guidance from the government, which provides reasonable defaults, which the parent can override.

These controls are much harder to circumvent – you can’t VPN out of an OS-level ban or an OS-level firewall which blocks outgoing connections, regardless of which your ISP is. It’s completely privacy-preserving, as users don’t have to show or prove anything.

Of course, the harder part is making sure every child and parent has a parental control app installed. Information campaigns and teachers can help with that, and I’m sure it will achieve much better results than what we are seeing in Australia for example.

Children protection agencies can even receive statistics for the number of changed preferences, to monitor for trends of parents just giving up and allowing whatever app the child wants. That’s why the first point in the above proposal is important – limit the addictiveness and brainrot on these platforms as a general rule, not just as a measure to protect children.

The problem is real, The Anxious Generation is spot in, and this mental health pandemic can have devastating long-term effects. That’s why we have to make the best possible decision on how to address it.

The post Age Verification Is A Bad Way To Solve The Problem of Children on Social Networks. What’s The Alternative? appeared first on Bozho's tech blog.

Introducing public preview runtimes on AWS Lambda, starting with Node.js 26 and Python 3.15

Post Syndicated from Jonathan Tuliani original https://aws.amazon.com/blogs/compute/introducing-public-preview-runtimes-on-aws-lambda-starting-with-node-js-26-and-python-3-15/

Today, AWS Lambda introduces public preview runtimes, a new way to try upcoming language versions on Lambda before their general availability (GA) release. Starting today, you can create and update Lambda functions using Node.js 26 and Python 3.15, the first runtimes available as public previews.

Previously, Lambda has always launched new runtimes as Generally Available (GA), giving you a production-ready experience from day one. But this means you couldn’t run your functions on Lambda using a pre-release language version, and we couldn’t hear your feedback while breaking changes were still possible. Public preview runtimes change that. By putting pre-GA runtimes in your hands months earlier, we can listen to your feedback and address it before GA, while we still have the opportunity to make breaking changes to improve the runtime.

Preview runtimes are available in all AWS commercial Regions, AWS GovCloud (US) Regions, and China Regions. They use the same runtime identifier as the eventual GA runtime, so your functions graduate automatically when the runtime reaches GA, with no action required.

Why public preview runtimes

When Lambda launches a new runtime as GA, that means it is ready for use in production workloads from day one. Historically, the Lambda team has validated new runtimes through internal testing and pre-release benchmarking. However, without real customer workloads running on the runtime, some issues only surface after the GA launch. And once the runtime is GA, the scope to address those issues is much reduced since we cannot risk breaking existing production workloads.

Public preview runtimes address this by opening up a pre-GA feedback window. During this period, you can deploy functions using the upcoming runtime, and the Lambda team can act on what you find, including making potentially breaking changes if necessary. In addition, because the upstream language is still in its pre-release phase, there’s also the opportunity that issues discovered during preview can be fixed in the runtime itself, not just worked around.

This benefits everyone involved. You get a runtime that’s been tested against a broader range of real workloads before it reaches GA. Third-party partners, including observability providers, infrastructure-as-code tools, and deployment frameworks, get time to validate compatibility. And upstream language communities get a signal from a major cloud platform while they can still act on it.

This is the first time we’re launching runtimes as public previews. As such, it’s an experiment. We hope to make public previews the default for all future runtime launches, depending on the success of this experiment and the feedback we receive.

What’s included in the preview runtimes

The Node.js 26 and Python 3.15 preview runtimes are built on the latest upstream pre-release of each language version. At launch, they are a straightforward version bump. There are no additional Lambda-specific enhancements beyond what the new language version itself provides. For details on what’s new in each language version, refer to the upstream release information:

Preview runtimes are available as both managed runtimes and base container images. The base images are published to the Lambda base image ECR repository with image tags starting with 3.15-preview (for Python) and 26-preview (for Node.js).

During the preview period, we may introduce additional features or enhancements to these runtimes. When we do, we’ll announce them on the same GitHub issue we use to collect your feedback:

Follow these issues to stay informed of any changes during the preview period.

What to expect during preview

Preview runtimes follow the same patching cadence as GA runtimes. When an update is released upstream, Lambda applies it to the preview runtime on the same schedule as any other supported runtime. All Lambda features supported by the current GA runtimes are available on the preview runtimes, including Lambda Managed Instances and durable functions.

The key difference is that the underlying language version has not yet reached its stable release. In addition, the Lambda team is still working on the runtimes to add features and optimize performance. This means breaking changes may occur during the preview period. A function that works today may require a fix after Lambda rolls out the next runtime update. This is by design: the preview period exists so that these issues can be found and resolved before GA, not after.

Because of this potential for breaking changes, preview runtimes are not covered by the AWS Lambda SLA or AWS technical support plans. We strongly recommend against using them for production workloads. Lambda emits a warning message to CloudWatch Logs on each cold start to make it clear when a function is running on a preview runtime:

WARNING: This is a preview runtime version and should not be used for production workloads. For further information and to provide feedback, see https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html.

You may notice that, at launch, preview runtimes have slower performance than GA runtimes, in particular for cold starts. This is because of a combination of lack of optimization and less caching in internal Lambda sub-systems. We will benchmark and optimize performance during the preview period, prior to GA.

Functions that use preview runtimes are billed at standard Lambda rates. There is no additional cost or separate pricing.

Share your feedback

We want to hear from you during the preview period. We’ve created a dedicated GitHub issue for each preview runtime where you can share your experience:

Comment on these issues directly, or open a separate issue in the repository if you prefer.

We’re interested in all feedback, not just bug reports. If you see an opportunity to take advantage of a new language feature in the runtime, or a way to improve the Lambda programming model for that language, we want to hear about it. The preview period is when we can still make meaningful changes, so this is the best time to share your ideas.

Note that feedback should be scoped to the runtime itself: the execution environment, language integration, and programming model. For broader Lambda feature requests, refer to the AWS Lambda public roadmap.

Transition to GA

Both Node.js 26 and Python 3.15 are expected to reach their stable upstream releases in October 2026. Lambda GA for each runtime is targeted within two months following those releases. For the latest estimated GA dates, see Lambda documentation.

For Node.js, the GA timeline is tied to the Node.js “Active LTS” release, which is scheduled for October 2026. Only at that point is the release considered suitable for production workloads by the Node.js project, and only then is it sufficiently stable for Lambda’s automatic runtime patching in which patches are applied to your functions without action on your part. Lambda will not GA the Node.js 26 runtime until it reaches Active LTS.

When a preview runtime reaches GA, your functions graduate automatically. The runtime identifier does not change: nodejs26.x in preview is the same nodejs26.x at GA. You do not need to update your function configuration, templates, or code. The preview label is removed from the console and documentation, the runtime becomes covered by the Lambda SLA and AWS Support, and the GA performance and quality bar applies from that point forward.

If you have pinned your function to a specific runtime version using Runtime Management Controls during the preview period, it remains pinned. You can unpin at any time to move to the GA runtime. Functions pinned to a pre-GA runtime version are not covered by the Lambda SLA and AWS Support.

Getting started

You can start using the Node.js 26 and Python 3.15 preview runtimes today using the Lambda console, AWS Command Line Interface (AWS CLI), AWS CloudFormation, AWS Serverless Application Model (AWS SAM), or AWS Cloud Development Kit (AWS CDK).

Console

In the Lambda console, choose “Node.js 26 (Preview)” or “Python 3.15 (Preview)” from the runtime list when creating or updating a function.

Screenshot of the Lambda console runtime list showing “Node.js 26 (Preview)” and “Python 3.15 (Preview)” options.

AWS CLI

Create a function using the preview runtime with the standard runtime identifier:

aws lambda create-function \
  --function-name my-function \
  --runtime nodejs26.x \
  --handler index.handler \
  --role arn:aws:iam::123456789012:role/my-role \
  --zip-file fileb://function.zip

For Python 3.15, use --runtime python3.15. These are the same identifiers the GA runtimes will use, there is no separate preview-specific value.

AWS CloudFormation

Specify the preview runtime in your CloudFormation template using the same runtime identifier:

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: my-function
      Runtime: nodejs26.x
      Handler: index.handler
      Role: arn:aws:iam::123456789012:role/my-role
      Code:
        S3Bucket: amzn-s3-demo-function-code
        S3Key: function.zip

AWS SAM

AWS SAM supports preview runtimes using the standard runtime identifier in your template:

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.15
      Handler: app.lambda_handler
      CodeUri: src/

When you run sam init, preview runtimes appear in the template list with a “(Preview)” label, so you can scaffold a new project directly.

AWS CDK

The AWS CDK does not yet include built-in enum members (such as Runtime.NODEJS_26_X). During the preview phase, you can use the public Runtime constructor to specify the runtime directly, for example:

import { Stack, StackProps } from "aws-cdk-lib";
import { Construct } from "constructs";
import { Function, Runtime, RuntimeFamily, Code } from "aws-cdk-lib/aws-lambda";

export class LambdaStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new Function(this, "MyFunction", {
      runtime: new Runtime("nodejs26.x", RuntimeFamily.NODEJS),
      handler: "index.handler",
      code: Code.fromAsset("lambda"),
    });
  }
}

Or, for Python 3.15, replace new Runtime("nodejs26.x", RuntimeFamily.NODEJS) with new Runtime("python3.15", RuntimeFamily.PYTHON).

This synthesizes identical CloudFormation to what a built-in enum produces. When the runtime reaches GA, a corresponding enum member will be added. There is no functional difference in the meantime.

Conclusion

Public preview runtimes give you a seat at the table while Lambda’s next runtimes are still taking shape. Try using Node.js 26 or Python 3.15 today to deploy a function, run your test suite, and let us know what you find.

Share feedback and follow along:

These GitHub issues are where we’ll post any enhancements or breaking changes during the preview period, so they’re worth watching even if you don’t have immediate feedback. The preview runtimes are available today in all AWS Regions, including AWS GovCloud (US), and the AWS China Regions. To learn more, see the Lambda runtimes documentation.

Metasploit Wrap Up: Lot of summer shells and fit http profiles

Post Syndicated from Rapid7 Labs original https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-lot-of-summer-shells-and-fit-http-profiles

This wrap-up brings a full-on shell parade. Thirteen shiny new modules landed, starting with a buffet of RCEs. WordPress WP2Shell, Ghost CMS, Joomla JCE, Langflow, OpenCATS, Pterodactyl Panel, SonicWall SMA1000, Ray Dashboard, a Pix-for-WooCommerce, and for those who like their exploits closer to the bare-metal, the Fragnesia Linux kernel LPE (CVE-2026-46300). Metasploit also got the glow-up of the summer with the new http malleable profiles, MCP functionality and linux multi fetch payloads (more details on the [official 6.5 release blog post](https://www.rapid7.com/blog/post/pt-metasploit-framework-6-5-released/)!). Windows on ARM confirm to be the new first-class citizenship thanks to brand-new AArch64 reverse-TCP shells (both inline and staged), so your Snapdragon boxes can join the party too. Last but not least, an important message: *Nyan Nyan Nyan Nyan Nyan Nyan.*

Screenshot_2026-08-14_162940.png

New module content (13)

Ray Dashboard Logs API Path Traversal

Author: Richard Howe <rhowe425>

Type: Auxiliary

Pull request: #21681 contributed by rmhowe425

Path: `gather/ray_dashboard_logs_api_path_traversal`

Description: This adds an auxiliary module that leverages a path traversal vulnerability in Ray to list the contents of local directories. There is currently no CVE assigned to this vulnerability. Issuance is pending with MITRE.

Pterodactyl Panel CVE-2025-49132 Remote Code Execution

Authors: 0xtensho and jheysel-r7

Type: Exploit

Pull request: #21452 contributed by jheysel-r7

Path: `linux/http/pterodactyl_locales_locale_json`

AttackerKB reference: CVE-2025-49132

Description: This adds a module which exploits a vulnerability in Pterodactyl Panel before version 1.11.11 that allows unauthenticated remote code execution through improper handling of locale file operations. The vulnerability, CVE-2025-49132, exists in the locale.json endpoint which allows path traversal and arbitrary file creation. This combination of capabilities results in remote code execution in the context of the user running the web server.

SonicWall SMA1000 WorkPlace wsproxy SSRF Remote Command Execution

Authors: Deral Heiland, Rapid7 Vulnerability Research, and Ryan Emmons

Type: Exploit

Pull request: #21678 contributed by dheiland-r7(https://github.com/dheiland-r7)

Path: `linux/http/sonicwall_sma1000_wsproxy_rce`

AttackerKB reference: CVE-2026-15409

Description: This adds a new exploit module for CVE-2026-15409, a Server-Side Request Forgery (SSRF) vulnerability in the SonicWall SMA1000 WorkPlace wsproxy service.

Fragnesia LPE (CVE-2026-46300)

Authors: William Bowling and msutovsky-r7

Type: Exploit

Pull request: #21456 contributed by msutovsky-r7

Path: linux/local/cve_2026_46300_fragnesia

AttackerKB reference: CVE-2026-46300

Description: This adds a local module for the Fragnesia exploit which is a page-cache replacement vulnerability in the Linux kernel’s XFRM (IPsec) subsystem, tracked as CVE-2026-46300.

Ghost CMS Remote Code Execution

Authors: Cristian-Alexandru Staicu and Maksim Rogov

Type: Exploit

Pull request: #21234 contributed by vognik

Path: multi/http/ghostcms_auth_rce_cve_2026_29053

AttackerKB reference: CVE-2026-22594

Description: This adds an exploit module for Ghost CMS (CVE-2026-29053) that achieves remote code execution by uploading a malicious theme. Ghost’s theme renderer evaluates untrusted JSONPath expressions through the {{#get}} helper, letting the module inject and trigger arbitrary code once a theme is uploaded and activated. You’ll need valid admin or staff credentials to authenticate.

Joomla Content Editor Unauthenticated File Upload RCE

Authors: David Jardin, Uwe Flottemesch, and ispyispyispy

Type: Exploit

Pull request: #21615 contributed by 15py15py15py

Path: multi/http/joomla_com_jce_unauth_file_upload_rce

AttackerKB reference: CVE-2026-48907

Description: This adds a new exploit module for CVE-2026-48907, an unauthenticated arbitrary profile creation vulnerability in the JCE (Joomla Content Editor) extension for Joomla!. The profiles.import task fails to enforce authentication, letting an attacker import a crafted profile that is written to disk as a PHP web shell, resulting in remote code execution when the tmp/ directory is directly accessible. All JCE versions up to and including 2.9.99.4 are affected, and no credentials are required.

Langflow Unauth RCE

Authors: Diamorphine and Richard Howe

Type: Exploit

Pull request: #21700 contributed by rmhowe425

Path: multi/http/langflow_unauth_rce_cve_2026_33017

AttackerKB reference: CVE-2026-33017

Description: Adds a new multi/http/langflow_unauth_rce_cve_2026_33017 exploit module that exploits an unauth RCE vulnerability in the /api/v1/build_public_tmp/{flow_id}/flow endpoint in Langflow versions prior to 1.9.0.

OpenCATS Installer PHP Code Injection

Authors: Chocapikk and stlthr4k3r

Type: Exploit

Pull request: #21630 contributed by stlthr4k3r

Path: multi/http/opencats_installer_rce

AttackerKB reference: CVE-2026-27760

Description: Adds an exploit module targeting CVE-2026-27760, a PHP code injection in OpenCATS.

WordPress WP2Shell REST API Batch Route Confusion SQLi to RCE

Authors: Adam Kues, Crypto-Cat, TF1T, dtro, and haongo

Type: Exploit

Pull request: #21686 contributed by Crypto-Cat

Path: multi/http/wp_batch_desync_rce

AttackerKB reference: CVE-2026-60137

Description: This adds an exploit module to target WP2Shell, an unauthenticated pre-auth remote code execution vulnerability affecting WordPress core versions 6.9.0–6.9.4 and 7.0.0–7.0.1. The module chains a REST API route confusion flaw (CVE-2026-63030) with an SQL injection (CVE-2026-60137) to elevate privileges, deploy a payload via a custom plugin, and execute a remote session.

WordPress Unauthenticated RCE via Pix for WooCommerce plugin

Authors: Alexis Lafontaine and Maksim Rogov

Type: Exploit

Pull request: #21683 contributed by vognik

Path: multi/http/wp_plugin_pix_unauth_rce_cve_2026_3891

AttackerKB reference: CVE-2026-3891

Description: Adds CVE-2026-3891 WordPress Unauthenticated RCE Exploit module targeting Pix for WooCommerce plugin.

Release Metasploit 6.5

Authors: OJ Reeves, Spencer McIntyre

Type: Payload (Single) Pull request: #21728 contributed by zeroSteiner

Description: Adds support for a new MALLEABLEC2 option to Meterpreter HTTP(S) payloads. This feature enables users to load a standard profile into Meterpreter and change the shape of its HTTP(S) traffic. All Meterpreters, including Windows, Java, Python, PHP and Linux, have been updated with this functionality.

Windows AArch64 Command Shell, Reverse TCP Inline

Author: vinicius-batistella

Type: Payload (Single)

Pull request: #21589 contributed by vinicius-batistella

Path: windows/aarch64/shell_reverse_tcp

Description: Adds Windows on ARM (AArch64) reverse-TCP command-shell payload.

Windows AArch64 Command Shell, Windows AArch64 Reverse TCP Stager

Author: vinicius-batistella

Type: Payload (Stager)

Pull request: #21744 contributed by vinicius-batistella

Path: windows/aarch64/shell/reverse_tcp

Description: Adds Windows AARCH64 staged shell payloads.

Enhancements and features (15)

  • #21379 from g0tmi1k – This improves the FTP login scanner by extending the reporting logic and adding extra checks
  • #21575 from g0tmi1k – Improves scanner/ftp/ftp_version to now report the service if host is up but we don’t get an appropriate FTP banner
  • #21578 from arpan-pramanik – Fixes a bug where msfconsole crashes with an unhandled exception when attempting to exit if the msf database is missing
  • #21607 from Pushpenderrathore – This extends CertificateTrace peer cert tracing to support LDAP over TLS and RDP
  • #21608 from Pushpenderrathore – This adds CertificateTrace peer cert tracing to PostgreSQL over TLS, and fixes a long-standing gap where the Postgres mixin accepted an SSL datastore option but never passed it through to the underlying connection
  • #21622 from zeroSteiner – Adds Bearer Authentication to the MCP server plugin
  • #21638 from eve0805 – This reuses the existing Kerberos ticket trace formatting for offline Kerberos artifact workflows, so stored and converted tickets can be inspected with the same output style used during live Kerberos authentication
  • #21653 from cdelafuente-r7 – This adds job tracking via run_uuid across all module types when executed through RPC endpoints to support Model Context Protocol (MCP) tool integrations
  • #21654 from cdelafuente-r7 – Adds eight new MCP tools: that wrap the existing RPC endpoints for module and session control, backed by strict per-tool input validation with an opt-in flag for dangerous actions
  • #21667 from jburgess-r7 – This updates the gogs_rebase_rce module with the vulnerability’s newly assigned CVE, CVE-2026-52806
  • #21691 from eve0805 – This adds KerberosTicketTrace support to the auxiliary/admin/kerberos/forge_ticket module
  • #21697 from bwatters-r7 – Adds explicit endianness to fetch multi payload query strings and encodes the fetch command in base64 for Python 3.8+ environments
  • #21728 from zeroSteiner – Adds support for a new MALLEABLEC2 option to Meterpreter HTTP(S) payloads
  • #21748 from zeroSteiner – Nyan Nyan Nyan Nyan Nyan Nyan!
  • #21768 from adfoster-r7 – Updates the default authentication logic in the JSON RPC support to now require auth by default, either via the database with user credentials or an auth token

Bugs fixed (15)

  • #21552 from stzifkas – Fix LHOST validation rejecting tunnel hostnames when DNS lookup fails
  • #21574 from g0tmi1k – Fixes the implementation of the FTP mixin to allow for reading multiple responses on the same TCP segment
  • #21609 from dwelch-r7 – Fixed an issue where payload option validation was delayed until after running show options, ensuring options like LHOST and LPORT are validated immediately upon setting a payload or loading a module
  • #21647 from jheysel-r7 – This updates the ntlm_relay_2_self module to automatically configure Resource-Based Constrained Delegation (RBCD) on the target machine account by setting its msDS-AllowedToActOnBehalfOfOtherIdentity attribute
  • #21659 from dwelch-r7 – This improves port conflict handling for the MCP plugin by adding pre-flight availability checks, post-spawn verification, and proper state resets on failure
  • #21661 from kx7m2qd – Fixes an issue with Ctrl+C handling regarding the MCP plugin
  • #21663 from zeroSteiner – Updates the error handling in the auxiliary/admin/dcerpc/icpr_cert module
  • #21687 from zeroSteiner – This updates and centralizes the warning message that’s displayed when a user sets a datastore option that is not valid in the current context
  • #21699 from sjanusz-r7 – Fixes a FrozenError issue when the DNS feature was enabled, which occurred when attempting to mutate frozen strings in place during DNS queries
  • #21701 from cdelafuente-r7 – This fixes an issue where exploit error messages were captured by the job listener during execution but hidden from the console
  • #21711 from cdelafuente-r7 – This fixes a Ruby 3 keyword argument parsing issue in run_simple, exploit_simple, and check_simple where passing a braceless hash literal caused an ArgumentError
  • #21714 from l1ve709 – Fixes typos in various module docs
  • #21718 from sjanusz-r7 – Fixes a crash when attempting to run VNC sessions from Metasploit
  • #21722 from dwelch-r7 – Fixed a regression to now again allow 0.0.0.0 as a valid listener LHOST address
  • #21759 from adfoster-r7 – Fixes a crash on multiple SMB modules when attempting to register an SMB service

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro.

Friday Squid Blogging: Searching for the Colossal Squid

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/08/friday-squid-blogging-searching-for-the-colossal-squid-2.html

Fascinating video about searching for life undersea. The video basically makes the point that our bright white searchlights are scaring everything away, and that red light is more neutral. That, plus bait to attract sea creatures, is teaching us a lot about what’s going on down there. Lots of footage of giant squid, and speculation about the colossal squid. Worth watching.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Blog moderation policy.

160-bay NVMe SSD 4U Server Shown at FMS 2026 Supermicro ASG-4116S-NU160R

Post Syndicated from Eric Smith original https://www.servethehome.com/160-bay-nvme-ssd-4u-server-shown-at-fms-2026-supermicro-asg-4116s-nu160r/

On the FMS 2026 show floor, we saw a massive 160-bay NVMe storage server (Supermicro ASG-4116S-NU160R) that can deliver crazy storage density

The post 160-bay NVMe SSD 4U Server Shown at FMS 2026 Supermicro ASG-4116S-NU160R appeared first on ServeTheHome.

The collective thoughts of the interwebz