CyberWire Daily [Research Saturday] - "A Fine Pearl Gone Rusty"

Date: November 8, 2025
Host: Dave Bittner (A)
Guests: Tal Peleg (C), Senior Product Manager at Varonis; Koby Abrams (B), Cybersecurity Researcher at Varonis
Main Theme:
Exploring the discovery, impact, and remediation of a critical remote code execution (RCE) vulnerability in PostgreSQL managed database environments—specifically through the intersection of Perl and Rust language extensions, impacting cloud providers like AWS.

Episode Overview

This episode centers around groundbreaking research by Tal Peleg and Koby Abrams of Varonis, who uncovered a remote code execution vulnerability affecting PostgreSQL databases using Rust (PL/Rust) and Perl language extensions. The discussion explores how they found the bug, the technical details of the exploit, their cooperative disclosure experience with AWS and PostgreSQL, and the broader implications for cloud security and responsible research.

Key Discussion Points & Insights

1. Background and Vulnerability Context

• Why "Rusty Burls"?
  • Koby: "Rustic Burls is actually just from the languages that the vulnerability uses. The vulnerability is in two language extensions in Postgres and those language extensions are Rust and Perl." [01:27]
• What Does RCE Mean in This Context?
  • Tal explains the difference between normal database queries and true remote code execution, emphasizing the elevated risk when attackers can run commands on the underlying system, even when not in superuser mode. [02:27]

2. Discovery Journey

• Initial Hypothesis:
  • Tal was examining a ticketing system database, suspecting these internal systems hold sensitive data and may be overlooked in routine security audits. When he found "a pretty major SQL injection", he tested its practical impact within an AWS RDS PostgreSQL instance. [03:02]
• Obstacles in Managed Databases:
  • He notes, "AWS provides us with an administrative user, but not a super user... what I was trying to do is find a way to escape that." [04:23]

3. Extension Exploration

• Third-party and Official Extensions:
  • Tal investigated less scrutinized third-party extensions and focused on built-in language support—particularly Perl for its legacy codebase and Rust for its newer integration. [05:15-08:34]
• Key Quote:
  • "Third party extensions can be less rigorously tested, not tested in all the same environments." – Tal [05:15]

4. Exploiting the Extensions

• Perl as the Entry Point:
  • By modifying environment variables via Perl (normally restricted to superusers), they could influence how code was executed by other components.
• Rust as the Execution Path:
  • Koby explains that because the PL/Rust extension spawned processes directly (bypassing PostgreSQL's normal APIs), it inherited the environment variables manipulated via Perl. This allowed execution of arbitrary code. [08:40]
• Quote:
  • "We found that there was a little bit of validation... and we were able to find an environment variable that wasn't in that deny list that was able to be used to execute code." – Koby [09:58]

5. Testing on AWS and the Human Element

• Live Experimentation:
  • After successfully exploiting the issue locally, the team nervously tested on AWS RDS, which resulted in AWS security quickly contacting them. [13:51]
• Quote:
  • "AWS were trying to contact us... They actually sent me a LinkedIn message. Like they were very adamant on finding out who exactly was running code on their RDS instances." – Koby [14:18]

6. AWS & Vendor Response

• Positive Collaboration:
  • AWS promptly detected the anomalous activity, isolated the instance, and worked collaboratively with Varonis and PostgreSQL to remediate the vulnerability swiftly. [15:54-16:04]
• Quote:
  • "They helped us... and making sure that things were fixed quickly and patching it on their servers, asking us to test it and really just being really responsible about it." – Koby [16:04]

7. Public Disclosure and Community Impact

• The team presented their findings at BSides Las Vegas and DEF CON, sharing learnings with the security community. [17:18-17:59]

Practical Security Recommendations

For PostgreSQL Database Administrators & Users

• Upgrade:
  • "Upgrade at least the minor versions of databases. I know it's a little bit difficult, but it's always a good idea." – Tal [18:17]
• Access Controls and Roles:
  • "Use roles... to limit who can create extensions, who can access which databases, which tables and everything."
• Restricted Extensions:
  • "Postgres also has a configuration variable, allowed extensions, that specify which extensions you can install on the database. I would recommend using that variable and only using extensions that you know that you're using."

For Cloud Providers

• Shared Responsibility:
  • "There is a shared responsibility here and sometimes that's confusing both to the customer and maybe to the cloud provider." – Tal [20:38]
• Security Integration:
  • Cloud providers should provide strong validation, monitor for abuse, ensure patching routines, and foster collaboration with researchers.

For Security Researchers

• Set Clear Research Goals:
  • "Setting your goals when you're researching is really important... that goal allows you to... focus and have that goal in mind to be able to succeed in the end." – Koby [22:36]

Notable Quotes & Memorable Moments

• On the "aha" moment during exploit development:
  • "Suddenly you see the command running. It's pretty fun." – Koby [10:30]
• On AWS response:
  • "Within a very short amount of time from us running code, they were able to block our access completely... making sure that everybody's data stays safer, which is all of our goals at the end of the day." – Koby [16:04]
• On cloud credential risk:
  • "If you have cloud credentials inside of your database, suddenly a simple SQL injection can turn into a complete cloud compromise and lateral movement, even between accounts." – Tal [21:44]
• Lesson for the research community:
  • "Having [research goals] there is a good idea, I think." – Koby [23:20]

Timestamps for Important Segments

• [01:27] - Vulnerability overview; naming origin
• [02:27] - RCE in PostgreSQL explained
• [03:02] - Discovery journey begins
• [05:15] - Focus on extensions and privilege escalation
• [08:34] - Koby joins; Rust extension path discovered
• [10:30] - Successful code execution moment
• [13:51] - AWS detection and outreach
• [16:04] - AWS's collaborative response
• [17:18] - Public disclosure, presenting at DEF CON
• [18:17] - Recommendations for locking down PostgreSQL
• [20:38] - Shared responsibility in the cloud
• [22:36] - Lessons learned from the research process

Conclusion

This episode provides an in-depth look at the risks posed by composable vulnerabilities in managed databases, particularly when mixing newer (Rust) and legacy (Perl) functionality. It highlights the importance of proactive research, responsible disclosure, active monitoring by cloud providers, and the use of sound configuration and access controls by end users.

Recommended Action: Keep PostgreSQL deployments updated, restrict extensions, enforce role-based access, and collaborate with cloud providers on security issues.

Speakers:

• Dave Bittner (Host)
• Tal Peleg (Guest, Varonis)
• Koby Abrams (Guest, Varonis)

Episode Title:
A fine pearl gone rusty – Uncovering RCE in PostgreSQL with Rust and Perl Extensions