A fine pearl gone rusty. [Research Saturday]

Summary

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

Transcript

[A]

You're listening to the Cyberwire network, powered by N2K. At Talas, they know cybersecurity can be tough and you can't protect everything. But with Thales, you can secure what matters most. With Thales industry leading platforms, you can protect critical applications, data and identities anywhere and at scale with the highest roi. That's why the most trusted brands and largest banks, retailers and healthcare companies in the world rely on TALAS to protect what matters most, applications, data and identity. That's Talas. T H A L E S learn [e-mail] cyber hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Buettner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us.

[B]

So 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. So if you're imagining, you can either imagine a rusty pearl kind of like in Pirates of the Caribbean, or you can imagine the language extensions, the different syntaxes and whatnot.

[A]

Our guests today are Tal Paleg, senior Product Manager, and Coby Abrams, cybersecurity researcher at Varonis. The research we're discussing is titled Rusty Remote Code Execution in Postgres Instances. Tal, could you walk us through what remote code execution vulnerabilities mean when it comes to postgres and what that means for, for organizations?

[C]

Sure. So a Postgres database, usually you can execute queries on them. Sometimes you have a web application or some other thing that's running a query on the data that you put in your database, but that database is hosted on some system. And actually what a remote code execution. In this case what it let us do is actually run commands on the underlying system.

[A]

So let's go through the journey of discovery here. But what led you down this path of exploration?

[C]

So I was looking at a ticketing service for just understanding how to secure it in our platform and also trying to look for vulnerabilities since these are less explored areas. Most people, most companies look at maybe file storage or virtual machines, containers, workloads. And we thought, well, ticketing systems, they have all the stuff that's happening inside the company. People are sending information to one another maybe about customers, maybe about maybe these contain sensitive data. Maybe a customer is asking a question and their question contains some sort of sensitive data. So this place is a treasure Trove of sensitive information. And so I was looking at one of these ticketing systems and I found a SQL injection and it was a pretty, pretty major SQL injection. And I thought, well, what would happen if I was an attacker? What impact could I have done? And so I set up a postgres instance on AWS rds, which is where this, where this ticketing system was hosting its own database. And I just wanted to see what impact I could do with just a database. And so what I noticed is that AWS provides us with an administrative user, but not a super user. So a super user in a database is able to control the entire database, change settings, even run commands on the system. But this user is not a super user and they cannot run commands on the system, they cannot open sockets, they can't access files on the system apart from very, very specific files. And so what I was trying to do is find a way to escape that and either escalate privileges to a, to a super user or in some other way run commands on the system.

[A]

Well, take us down that path. How did you go at this.

[B]

This.

[A]

Question that you'd asked yourself?

[C]

So I started by looking at extensions. And extensions are placed that are sometimes not tested as heavily. So the database itself is open source. Lots of people have been looking at it. It exists since the, I don't know since when it exists for a long time. Postgres is one of the more well known databases and hopefully that means it's pretty secure. But third party extensions can be less rigorously tested, not tested in all the same environments that the database was tested in, maybe interactions between different extensions, since they are usually not tested together, all the different combinations that you can make. So I was looking at extensions. One extension that had a vulnerability for accessing files is a logging extension. Something that I've noticed, but someone already disclosed it before I was able to. But I continued looking at extensions and I was thinking, okay, functions, triggers, maybe something that I can cause the super user to run in order to bring me higher privileges. So I was looking at functions, I was looking at extensions. I thought, well, there are language extensions. And then one that caught my eye is Perl, since Perl exists in the Postgres repo. So it's an official language, it's also open source, it probably exists in lots of Postgres installations. And so it would be pretty impactful to find something there. And also Perl is from the 80s, so there's a lot of code written in Perl. That's before security was really or Code security was really popular. People didn't really think about all the, about vulnerabilities and privacy and data security. So I was looking at Perl, and Perl has an interface to manage environment variables. And managing environment variables is one of the things that only a super user should be able to do. So I thought, well, maybe this interface, which is a magic variable in the function, would let me modify environment variables. And it turned out to be true. So I was able to set environment variables, and then I was looking for some way I could use those environment variables in order to run code. And I looked specifically at extensions that were allowed in aws, RDS Aurora, or AWS Aurora, and I actually wasn't able to find anything. And I put that aside for a little while, and then, and then I got Kobe up on the team.

[A]

Koby, do you. Do you want to jump in here and describe your contributions?

[B]

So when, when, when Tal told me that he has a. He has this primitive, I was, I was really excited. It sounded really cool. But Postgres kind of makes it difficult to execute code using environment variables, because as an extension, when you create a new process as an extension in Postgres, you actually have an API that Postgres gives you to create that process, and you're not creating it as a child of your own. So it's not taking those environment variables that you've edited in Perl and then creating the process with them, which, which makes it difficult because the processes that you're now creating have their own environment variables that, that aren't edited. So what, what we looked for was a. An extension that creates processes directly without using this API. Right. So it's doing something that it's not really supposed to do. And what we found was that PL Rust, which is a fairly new extension, actually creates processes directly when it's compiling the Rust function. So that was pretty cool. And once we were able to find that, we found. So basically we found that there was a little bit of validation. There is a deny list that denies certain environment variables from being edited while Rust is compiling. While PL Rust, the extension is compiling your function. 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. So it was pretty cool, especially seeing it work when we were. I was kind of skeptical that we were going to be able to at this point. And suddenly you see the command running. It's pretty fun.

[A]

Yeah, I suspect, I mean, for both of you, that must be a gratifying kind of Aha moment, right.

[C]

We even took it a little bit far. So we were try, we, we saw we were able to execute code on our own postgres instance in a container. And so we thought well, let's see if this thing works on the cloud on aws.

[A]

We'll be right back.

[D]

What happens when cybercrime becomes as easy as shopping online? Spy Cloud's Trevor Hilligoss joined Dave Buettner on the Cyberwire Daily to explain how a wave of cybercrime enablement services are lowering the barrier to entry and making sophisticated attacks available to anyone.

[E]

I think it's a pretty good general term that describes kind of an umbrella of tools and services that I would kind of tag as criminal or criminal adjacent. Instead of having sort of the smaller pool of high sophistication actors that are able to kind of carry out these really vast and costly cyber attacks, we see that being given to much lower sophistication, lower tech folks that are a much lower barrier to entry. To get into this field, the person that's buying access to this, they basically need a phone and a bitcoin wallet.

[D]

Make sure you hear this full conversation and learn how the underground economy is reshaping Cyber risk. Visit explore.thecyberwire.com spycloud that's explore.thecyberwire.Com spycloud.

[A]

Foreign they know cybersecurity can be tough and you can't protect everything. But with Thales, you can secure what matters most. With Thales industry leading platforms, you can protect critical applications, data and identities anywhere and at scale with the highest roi. That's why the most trusted brands and largest banks, retailers and healthcare companies in the world are rely on Thales to protect what matters most. Applications, data and identity. That's Thales. T H A L E S learn [e-mail] Cyber this is a real good story about Bronx and his dad Ryan. Real United Airlines customers. We were returning home and one of the flight attendants asked Bronx if he wanted to see the flight deck and meet Captain Andrew.

[B]

I got to sit in the driver's seat.

[E]

I grew up in an aviation family and seeing Bronx kind of reminded me.

[C]

Of myself when I was that age.

[A]

That's Andrew, a real United pilot.

[C]

These small interactions can shape a kid's future.

[A]

It felt like I was the captain. Allowing my son to see the flight deck will stick with us forever.

[C]

That's how good leads the way.

[B]

So we did want to check this out on aws. We were kind of wondering. We went and we read all of the different disclaimers that Amazon put out, trying to figure out if like we were allowed to at all. And it was a bit of a gray area, but we decided to go for it anyways. And of course we did it on Thursday, like just before the weekend, kind of in the evening, and ended up causing, causing some issues because we were unavailable after that. And AWS were trying to contact us and they're getting in touch with our bosses and they're trying to call 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.

[A]

So I guess the good news is AWS detected it. The bad news for you all is that they knew it was you, Right?

[C]

Well, it could be bad, but it's also pretty good because actually we got a nice collaboration out of it. So they were being very responsive. They thought we were researchers since Veronis, a security company and we do security research on AWS and we do protect our customers, AWS environments. So they know what we do. And they saw that the account was called something with the word research in it, but still running code. It was actually a holiday or just before a holiday, and it was right before the weekend. And so they were a little bit unsure of whether it was a legitimate research or maybe someone compromising the environment.

[A]

Yeah, that's interesting. I mean, everybody in security gets, I think, a little on edge when we come up on a long holiday weekend. Right. History has taught us to be extra vigilant.

[C]

Yes, for sure.

[A]

So what was AWS's response here? You had this positive interaction with them. What ultimately did they do to protect their managed databases?

[B]

So within a very short amount of time from us running code, they were able to block our access completely. They put the database in a, in a, in a stage, in a. In a. In a mode that we, we couldn't run, continue running code. They also reached out to us to make sure that we were actually researchers. So they were really good. And, and once, you know, we got in touch with them and contacted them, they helped us. Because it's a third party vulnerability, right? It's not really a vulnerability with aws, it's more postgres vulnerability. They were also really helpful in contacting the postgres team 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 and helping us to make sure that everybody's data stays safer, which is all of our goals at the end of the day.

[A]

Right.

[C]

And after we talked about this in Vegas a few weeks ago, we also were able to actually meet the team that responded to this incident. So that was pretty cool too.

[A]

Oh, that's great. I mean, you two did present at DEFCON this year, so it sounds like it was really a positive experience all around.

[B]

Yeah, so we were able to present at Bsides Las Vegas and at DEF con which was really nice. You know, that experience of speaking at DEF CON and you know, getting on the big stage was really exciting for the both of us. We were a little nervous as first time speakers, I think. Luckily it was kind of the end of the day and it was a little more low key, like not such a big talk. But I think it was really great and really exciting and it was an interesting experience. I really look forward to being able to do it again.

[A]

Well, congratulations to you both. I'm curious, in terms of solutions here and recommendations for people who are using Postgres, what sort of practical steps should they be taking, I guess, to lock down these extensions? Is that what we're talking about here?

[C]

So first of all, I'd say upgrade at least the minor versions of databases. I know it's a little bit difficult, but it's always a good idea. Use roles. So Postgres, but also other databases have role based access controls. Use those to limit who can create extensions, who can access which databases, which tables and everything. And apart from this, postgres also has a configuration variable, allowed extensions, that specified which extensions you can install on the database. So if an extension doesn't exist there, you won't be able to install it if you use that variable. So I would recommend using that variable and only using extensions that you know that you're using.

[A]

Anything to add, Coby?

[B]

Yeah, I think, I think there's also something to be said for the cloud providers side of things in this, in this case, right. We're not just running code on any database, although this vulnerability works in most Postgres databases that have the two extensions installed. But when it's when, when you're running code on a cloud provider's backend, right, there are various things that you might be able to do. You might be able to access credentials that shouldn't be accessed. You might be able to have network access to different tenants. And I think it's really important. This isn't the first time that a vulnerability that allows executing code on database backends has come out and especially when they can be run on cloud providers. We need to be able to have research like community research on those backends to figure out if there are credentials that shouldn't be there, if there are network access that shouldn't be allowed, if there are container escapes that we can implement there. So I think the cloud provider also has a really large amount of. So the cloud provider has a lot of attack surface there.

[A]

So Tal, when it comes to specifically dealing with the cloud, are there any specific messages you want our listeners to take away from this?

[C]

All right, so in the cloud, managed databases are managed by the cloud provider, but the data is managed by, by the cloud customer. So there is a shared responsibility here and sometimes that's confusing both to the customer and maybe to the cloud provider. And so you need to be extra careful in how you manage your data in the cloud. So while problems like issues like this one, a vulnerability in the database itself is something that the cloud provider should manage, since the extension is something that the cloud provider provides and doesn't allow the customer to manage themselves. The customer should still be sure to use the proper security controls, not let just anyone access their database and keep their databases private. Use role based access controls, like I said before, just in general, store the right data in the right places, use maybe rules to mask some of that data and so on. Another thing that exists in the cloud is cloud credentials. So maybe you want your database to access other data stores that are stored in the cloud, maybe you want other services to be able to access the database. And those integrations should also be managed carefully because 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.

[A]

Well, Kobi, can we touch on the research itself and the lessons that you took away from actually going through this process?

[B]

Yeah, sure. So one of the biggest lessons I think we learned along the way is that setting your goals when you're researching is really important because otherwise things can get really, really hectic when you're researching. Like there are all kinds of different primitives that you can find and attack surfaces that you can look at. And if you just set your goal like when we found the, when Tal found the SQL injection injection, at some point he decided that's it, I'm going to find remote code execution on postgres and specifically RDS or Aurora. And you know, just that that goal allows you to be able to kind of weed through the things that are less important and to really focus and have that have that goal in mind to be able to succeed in the end. So I think that's that's one of the biggest lessons we've learned. Of course, there are other things like environment variables that are fun to use and things like that, but the main, the main goal is set your goals before you start researching. Of course, things might change along the way, but having them there is a good idea, I think.

[A]

Our thanks to Tal Peleg and Kobe Abrams from Veronis for joining us. The research is titled Rusty Remote Code Execution in Psych Postgres Instances. We'll have a link in the Show Notes and that's Research Saturday, brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the Show Notes or send an email to cyberwire2. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.