Welcome back after the lunch break.
I hope you're refreshed and sharp again.
As you can tell, the microphone, my microphone is now on the other channel.
So there won't be any more interference.
Welcome, Manja Neumann from Düsseldorf.
From Düsseldorf.
Manja is a web developer and worked on a client project
where a pentest — what that is, we'll find out in a moment —
was prepared, together with a client's website.
Manja will tell us about the pitfalls you can trip into everywhere.
Enjoy.
Hello from me too.
As mentioned, I'm Manja from Düsseldorf.
I'm glad we can now dive together into this fascinating topic
of internet security.
So to start, just to ease into the topic a bit.
Who here has ever been hacked, or has clients who were hacked?
Yes.
And for whom did that happen in the last four months?
Well, I have to say, on my clients' websites — not just client websites,
I mean I've dealt with an enormous number of hacks in the last few months,
right in front of me, and I also know why.
There are two reasons, and something is to blame for both
and we all know what it is: AI.
On one hand, we have the problem with AI that it finds vulnerabilities
and it's diligent, it can search all day and all night
and it finds something.
On the other hand, we have clients who suddenly think they can code.
You can't imagine what I've seen
in the last few months — straight from hell.
And now we have — well, together we now have a task,
we have a mission, we simply need to make websites better again.
We need to think of websites like a castle,
a medieval castle.
Ten years ago it was enough to build it on a hill,
but today we need a wall,
we need a drawbridge that gets closed at night,
we need a moat, we need crocodiles in the moat
and they need to be hungry.
We have to do a whole lot to keep the site secure.
And to test that, this kind of pentest exists.
But now.
What are we doing now?
So let me tell you, I had a client project
we spent two years building the website for an organization
and as soon as this organization goes live, it has to pass a pentest.
Getting hacked is not an option in this case — not at all.
So we prepared for this pentest,
we had it carried out, and I'll show you the results in a moment.
Right at the end, I'll give you a checklist
of what worked for us to pass the pentest.
It might be different things for you, but it's a good starting point.
That's me, I'm Manja.
I'm a WordPress and WooCommerce freelancer.
Together with some lovely people I organize the meetup in Düsseldorf
and every now and then a WordCamp too.
If you want to get in touch with me, feel free to find me on Instagram.
You could also try LinkedIn, but I'm rarely there.
I don't like it, not sure why.
So what is a pentest?
I've dropped that word several times now,
some of you might not actually know what it means.
Has anyone here ever been involved in a pentest?
Yes, great.
For everyone else.
So you hire one person, or several,
to hack into the system.
So you pay a lot of money for other people to try
to somehow break into the system.
And afterward they give you a list of how they managed it.
Above all, it's not an automated scan.
The test happens as a one-off.
Our pentest was supposed to follow OWASP.
That's what I was told beforehand, that was pretty much the only info I had.
Okay, OWASP, I looked it up.
What is it?
That's the Open Worldwide Application Security Project.
An organization that has made it its mission
to name and document vulnerabilities.
And they regularly publish a Top Ten list.
This Top Ten is based partly on real hacks,
so they analyze hacks, what happened,
how did people get in.
And partly also on a survey.
So this Top Ten includes both.
What the community thinks and actual figures.
So that's where you get to this OWASP project.
And there you can read up in great depth
and lose yourself in vulnerabilities.
Let's go through the Top Ten briefly now.
You can guess along and see what you think.
The first five are kind of, well...
But once we get into the Top Five, it gets exciting.
In tenth place.
Errors.
Okay, errors that reveal information.
That's not quite so bad in WordPress.
But there's a glaring problem.
If a plugin has an error and throws it out
and it isn't defined in the wp-config,
what happens with errors,
then it just gets shown in the frontend.
The audience might feel disturbed, irritated.
But someone who wants to hack into your website
can do quite a lot with that.
It's simply too much information.
Let's move to the next one.
Number nine.
Security logging and alerting failures.
Yes, so this is one of those community-flagged problems.
It hasn't been directly observed,
rather the community believes
that this definitely leads to problems
if you don't monitor attacks and failed attempts.
A very, very simple example.
I have a client where someone actually
created an admin user overnight
that the client doesn't recognize.
An email even went out, but to an info@ address.
The secretary didn't know what to make of it
and deleted the email.
And the IT department only found out two weeks later.
That could have been prevented.
Number eight.
Can someone modify files on your server without you noticing?
So here, for example, you could say
you can, for example, from the backend
in the Plugin Editor or the Theme Editor
change things very easily.
Super convenient, but you just shouldn't do it.
Good practice: just block it.
This also includes things like
the special offer from Avada.
Today it costs nothing on
some dubious site, I wouldn't do that.
That would then lead to this mistake.
Now it's getting exciting.
Here, probably everyone would say
that's just logical.
Passwords, two-factor, that's standard, right?
Nope, it's not.
I'm sorry to have to say this,
but even today, in 2026, it's not standard.
Not even that strong passwords are used,
or that two-factor authentication is in place.
That's actually not standard in practice.
And every time I shake my head.
In our case now, in my client project,
we had an additional problem.
The employees of this organization have to
hand in and lock away their phones at the entrance.
No phones are allowed to be used at the workplace.
They don't have their own email addresses
and no authenticator app is allowed on the PC.
Which means there's basically no two-factor available.
At first I thought, no problem at all,
we secure the login via a reverse proxy anyway.
That means the login is only reachable
if you're physically in the building,
on the network, or dialing in via VPN.
The pentester didn't initially agree with that.
I contacted him and explained the problem.
He wasn't too happy about it.
But I documented it again,
that it's impossible to hack in
if there's a secured login.
And I placated him by pointing out
that even though I use a VPN,
I will use two-factor because I have a phone.
And everyone else is now an editor and isn't allowed to.
That way we worked around the problem a bit.
So you actually can talk things through with people.
At first they said rules are rules, but it worked out.
So you just have to go back and forth a bit
when you have situations like this.
But in all other cases, I mean,
how many organizations actually forbid phones at work?
Insecure design — security aspects aren't planned in.
One really, really bad example of this.
You have a form, an application form,
and people can upload their resume.
If this form doesn't check what's actually in the file,
that can end badly.
Just try to use form plugins that you trust.
In general, form plugins are tricky.
A5, Injection.
Actually the most exciting and interesting one.
I would've said, until recently, a normal user would barely run into this.
But hey, now we can all code, apparently.
Don't do it. Just don't do it.
Especially not anything to do with forms, search, and things like that.
If you don't know what you're doing, please, please, please, please.
That's really dangerous.
Insecure and missing encryption.
Here too you'd think, come on, it's 2026.
But honestly, why does every website have SSL?
Because otherwise Google penalizes it and browsers won't serve the sites.
Not because people think it's more secure for their site.
They were forced into it.
And now if I ask how many of you maintain your security headers.
Will every hand go up?
Yes? How many of you actually maintain your security headers?
Okay, we have homework.
Let's meet here again next week at the same time.
And then I want to see every hand up.
Yes, that's a follow-up.
That's really important.
I'd wish Google penalized that too.
If they're not properly maintained.
Here we get to another all-time favorite.
Vulnerabilities in plugins and themes. What helps against them:
Update, update, update.
Ten years ago I would've said, oh, automatic updates,
that could break the design.
Today I say, everything you trust, set it to automatic.
That way less can go wrong.
So what, the design gets a little off,
but at least the security hole is closed.
Or you just keep checking in constantly.
Bad or missing default settings are relatively rare in WordPress.
I'd say because we're just good at this.
We can give ourselves credit for once.
There are a few small things where you'd say,
I'd say the XML-RPC interface, for one.
Why does it need to be open if you don't need it?
Why? You could just close it.
It doesn't hurt.
Same with the REST API.
Why is it always completely open if you don't need it?
If you don't need it.
What you don't need, you can just turn off.
Broken access control.
Someone accesses things they shouldn't have access to.
It's been number one for years.
That means someone who isn't an admin gets to do admin things.
One example is that within an organization,
when adding a new user, everyone just gets admin rights right away
because you don't really know how the roles work — that's complicated too.
There's a reason WordPress has so many roles.
But how many of you at least set someone as editor only?
How many of you go down even just one level?
Ah, it's complicated, you'd have to look into it.
But yes, it's important.
So, very simple things.
But also other things — what else did I write down?
The REST API.
From this you could say, not everything is equally relevant for WordPress.
So what would you pick for your Top 5?
Just for yourselves — do you have a few favorites?
Feel free to think about it.
Passwords are definitely on there.
So we have configuration, injection here.
Wonderful. Authentication failures.
Broken access control.
And right at the top, plugins with vulnerabilities.
That means, I believe, 95% of all hacks happen because some plugin
has a vulnerability and wasn't updated.
That's unfortunately how it is.
I don't know how many of you know the "Swiss cheese model" of IT security?
Ah, some of you do.
Not every measure on my checklist
is the holy grail on its own.
Each one is fine by itself.
But you have to think of each one as a slice of cheese.
You have holes in the system, and you cover them one by one.
With every single slice you add, the holes become less likely to line up.
So the more layers you stack on, the better.
So, now I'd actually gotten everything ready.
I'd covered everything. I sailed right through.
I talked with the pentester again about that two-factor thing.
What could possibly happen?
We started the test.
Damn.
What had I not thought of?
I thought, oh no.
I hadn't thought of it.
Plugins.
So, of course we used plugins, and three plugins turned out to have a problem.
One plugin was a third-party plugin.
Two were from the plugin directory.
I wrote to the third-party plugin developer.
You can't just publicly call them out.
You just have to file a support ticket.
Which I did, and the response was:
We don't care.
You could just not use it, then.
That was the final answer.
They didn't address it.
The security issue is still there.
We simply had to remove the plugin.
We had no choice.
And now that feature just doesn't exist on the site anymore.
The second one said, yes, we're aware.
We've actually already fixed it.
Some themes still have an issue though.
You could try it and see if it works with your setup.
It worked.
That's the kind of support I wish for.
Wonderful, they answered quickly.
They acknowledged my problem and solved it.
The third one wrote back, that's not true.
Yes, it is true.
Nope.
What am I even supposed to say now, people?
By the way, the vulnerabilities are listed on Patchstack.
Here are the links.
Response.
You've published security-relevant information here.
And now all our users are at risk.
The post was deleted from the support forum.
Because of that.
I got in real trouble.
I got a very unpleasant message on Slack.
But it was worth it.
After two days the thing was fixed.
And I thought, fine, so I'm the bad guy, I don't care.
We can keep using the plugin.
So, that much.
Just make trouble, really push them.
Eventually people have to act.
At least if they're in the plugin directory.
Yes.
So the first and second attempt actually passed.
I was very happy.
And thought, okay, wait a minute.
Tomorrow we have to update.
What is this, actually?
A pentest is all well and good,
but there are really two problems.
One: WordPress is dynamic.
That means you actually have to internalize and live this pentest.
And also pass it on to the whole company.
They need to know what it's about.
You need to know what it's about.
And with every update you need to be critical.
With every new plugin you need to be critical.
With every new user you need to be critical.
That's just how it is.
Today your WordPress might have a thick wall made of stone.
Tomorrow it's a picket fence.
Could happen.
Or the cook installed a door so he could get to the market more easily.
All of that is possible.
Every day it's basically a new system.
Also, what I find a bit sad about pentests is,
what if someone gets in anyway?
I no longer believe
that a website can be unhackable.
I've seen too much garbage in the last few months.
Every website, I'm afraid,
you can break into any website.
But what happens then?
If someone has gotten through the wall,
what's behind it?
Another wall?
A guard dog?
A pit with spikes?
Like iron bars you fall into?
That matters too, right?
I think you should also think about
a few things, like with the pyramids —
they do have a door,
everyone knows where the entrance is,
but you still can't get to the burial chamber.
And if you want to try this out,
because not everyone
can afford a pentest,
that's a bit expensive,
there are actually two options.
You can
get a tool from OWASP,
the ZAP tool.
It's a really nice, compact tool.
There's a bit of a learning curve, it's complex,
but it has an MCP server.
It's a really nice, compact tool.
There's a bit of a learning curve, it's complex,
but it has an MCP server.
An MCP server.
Which means you can just
connect it to Claude and have it analyzed
to see what the issues are.
If you're a bit hesitant about that,
because it's a lot of effort,
you can also try WPScan instead.
That works really well
specifically for WordPress.
You can get an API key there
and then you can
just check the site
for vulnerabilities.
My checklist.
What did I do?
Now I'm trying
to open it up.
This is my checklist.
You can just use it.
It's basically yours then.
You can change it, extend it, delete things.
This might help you
bring a bit more routine
into the whole process.
Some things are obvious,
some a bit more complicated.
I've also sorted them by difficulty,
from easy to hard,
sorted.
It's located
behind this link.
Yes.
Okay, that's something.
Simon has been giving a critical look the whole time.
Really bad.
Thank you, Manja, for the
lively talk after the lunch break.
So.
I hope no one fell asleep.
No, I don't think so.
Do any of you
have questions, Manja — from Christoph?
I'd have an addition
to make here,
something I felt was a bit missing,
where you talked about users.
The offboarding process.
How often I've
seen it,
employee XY,
especially developer XY,
who had two-factor
access,
still has a live admin account,
but hasn't been with the company for two years.
Absolutely.
I actually also find it really, really
scary that clients sometimes call me
after three, four years
and say they have a problem.
And when I then say,
you need to give me access.
Oh, we still have that.
Guys, that wasn't the deal.
So, great tip.
Offboarding, yes.
Regularly review your admins.
Actually, review all users in general.
You can delete users
and create them again later
if they're needed again.
Or downgrade them.
You can also assign no role to someone
if you're not sure whether that person
will be needed again.
Yes, there's currently the problem
that the patches
aren't uploaded within 24 hours,
after the issue has already been fixed,
actually
they don't get uploaded.
So that you essentially can't do an automatic
update.
So that you still end up having to
ultimately do the whole thing
manually anyway.
That happened to us, there was
Burst as a statistics plugin
in a
That only took 5 hours.
Then the vulnerability at our end
had been exploited.
Even though in that case we
hadn't even gotten
any alert from the firewall yet.
You see, I know.
I know.
Absolutely.
No one is 100%
No one is 100% immune to that.
That's unfortunately how it is.
But what can you do about it?
That's actually
a really frustrating situation,
that something like this can even happen.
Yes, yes.
I think at this point we need to
thank Matt.
Yes.
I think,
here in this group we don't have
a way to do that.
We can barely hear you,
Gerd.
Never mind.
Yes, I'll just repeat
the question.
Yes.
Yes, it's annoying.
Definitely.
What was the most striking thing,
what was the most striking thing,
what was the most striking thing, where I most wanted
to pull my hair out?
So, the designer at a
big company, who's actually
responsible for branding
and gift packaging,
had an idea.
Well, having ideas is enough, right.
A really great idea.
It's like some kind of
calculator thing.
You could feed things
into it and it turned
into
a kind of, it was a
configurator on the website.
You could do really great things with it,
and it
sent its data
everywhere.
There were also things on his private server
where I thought,
but why hadn't anyone
talked to me about this?
Oh, well, that's just,
that's just AI-generated code, that doesn't concern you at all.
So also this idea,
that no one thought
to even mention it beforehand.
They just installed it
or put it in, because
it's just content, after all.
And they thought, if they only integrate content
through an HTML block like that,
that doesn't
mean anything. Not much can happen there.
It can, actually.
Yes.
Another example,
a managing director
has also just discovered
AI for himself and now writes
all his
blog posts with it.
And that
gets output to him completely
as HTML, but
including everything. So he
takes the whole document,
pastes it
into the HTML block. Which means
we now always have two headers,
two footers, and in between,
well, that's
now, let's say, that's now
not, I don't know, well,
he probably won't get hacked because of it,
since it really is just
HTML, but it
looks really terrible.
That one also made me
want to tear my hair out too.
I'm always speechless in those moments and
think,
I don't know.
Yes, maybe someone can educate me better
on this,
how to deal with something like that.
I'm honestly just always stunned.
How carelessly AI
is often used.
Anything else?
If a site has been hacked,
when should you rebuild
the system from scratch?
Well, so,
in that case I wouldn't first go
into a panic, but instead just
take stock,
take a look,
whether you've actually found something, exactly.
So
you should just try to find everything.
In a case like that, it's always useful
if you have an access log, because then
you can also see what was
accessed and what
was installed.
That's great for analysis. AI is
actually really good at analyzing this, by the way.
You can
those, well
I do it this way: WordPress gets
just freshly reinstalled, it just gets
reinstalled over it, so all
WordPress files are clean, the database has to
be checked,
the uploads directory needs to be searched, it needs to
very, very carefully
be searched,
there mustn't be anything hidden in there.
But other than that
a cleanup like that is actually fairly quick.
I'd say, 3-4 hours,
and then
it's usually done.
Yes.
The important thing is to close the door, but
yes.
Yes, but could the backup also be
affected? You don't know.
Yes.
Well, Thorsten said restoring the backup
is always good if
the backup is clean.
So the access log shows
you when things happened.
And there you can obviously check
whether you have a backup from before
that's clean, and if you have that
then of course you can restore it.
But the really important thing is closing the door.
That's why, I also have clients
who just quickly deleted their site,
but then, of course, you can no longer see
what happened, and then you can repair much,
much less than
if the site is at least still there.
So don't just
delete things. It's easier not to.
Yes, over there.
Yes, critical point.
So she's asking whether there are security measures
if you're not a developer.
Well, I'd say, first and foremost,
be critical.
Give as few
people permissions as possible
and
disable
as much as possible that
isn't needed.
So I'd say, first and foremost, be critical.
Give as few
people permissions as possible
and
whatever
could somehow cause problems.
Use few plugins, and if you do, from the
plugin directory, and keep them
up to date.
Never from untrustworthy sources.
That was my Avada offer.
For 0 euros.
That's never okay. There will
never be an Avada offer for 0 euros.
Yes.
She's asking what I think of
plugins like Wordfence
think of them.
Well, most of what
those do, you could
actually do yourself with quite simple means.
For one thing, Wordfence is
actually a good thing.
But it often lulls
you into a false sense of security
that isn't really there.
If you don't have the pro version,
the alerts come very, very late.
Actually it's useful if you
check the Wordfence blog.
Because that's where the plugins
and their vulnerabilities are kept up to date.
And in the free version
the alerts come way too late.
Yes, for two-factor there's a wonderful
plugin: Two Factor.
That does exactly that.
That's nice too.
I often get the feeling
that clients
install Wordfence
and then think they're now safe.
And I think that's
the worst part about it.
So on one hand they think they're safe, and on the other
they think they're being massively attacked because
this incredible flood
of background noise that's actually completely normal.
But Wordfence alone, just installing it,
doesn't make anything secure.
First you need to know how to configure it properly,
and second, you could actually do that
yourself anyway.
Personally, I don't think much of it.
But if someone likes to use it,
that's fine too.
But be critical.
Am I off the hook now?
I hate giving talks.
Dear Manja.
Thank you very much.
You get, like all speakers,
a little gift as well
with
Mannheimer Dreck — a local Mannheim pastry.
Yes, wonderful.
A local specialty. Exactly.
Thank you for being here.
Thank you very much.