Hiding in plain sight: HTTP request smuggling – 10 minute mail

HTTP request smuggling is increasingly exploited by hackers in the wild and in bug bounty programs. This post will explain the HTTP request smuggling attack with remediation tips.

What is HTTP request smuggling?

HTTP request smuggling is an attack technique that abuses how two HTTP devices send requests between each other (typically a front-end proxy or a HTTP-enabled firewall and a backend server) or chaining multiple servers together with different configurations.

The attacker is able to modify a request to include two requests within the body of a singular request by telling the server where the request ends by modifying the Content-Length, or Transfer-Encoding header. By abusing these headers, an additional request can be smuggled into the first, leading to the response of the smuggled request being attached to the response of another request. 

How is this caused?

HTTP specification allows a server to specify if the request has completed by using two different methods. Using Content-Length or Transfer-Encoding: chunked

The Content-Length header specifies the total size of the request body in bytes, whereas Transfer-Encoding: chunked specifies that the request body will be sent in chunks separated by newline sequences, with each chunk preceded by its size in bytes. The request body ends with a 0-length chunk.

Sending both of these headers in the same request is where the conflict can occur. 

Example of how this could be used

An attacker trying to access the admin page of a website which is normally blocked by a front-end server or Web Application Firewall.


Requesting example.com will result in a 200 response from the server, but when requesting example.com/admin, the server responds with a 403 Forbidden response. The request would look similar to this:

POST /admin HTTP/1.1
Host: example.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length :11


The front end server which received the request accepts that the request ends with the Content-Length of 11. The front end accepts the request and the Content Security Policy or Web Application Firewall that blocks the request and returns a 403.

If we modify the request to include a smuggled request, we would insert both of the Content-Length and Transfer-Encoding headers, making sure that we include the smuggled request.

POST /admin HTTP/1.1
Host: example.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length :11
Transfer-Encoding: chunked

POST /admin HTTP/1.1
Host: foo.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length :11
Transfer-Encoding: chunked


Sending this request multiple times will cause the request to go through, with the front end interpreting the first header of Content-Length,  with the back end using the Transfer-Encoding header. 

This will cause the secondary request to be attached to the response of another request. Being able to see this is dependent on the amount of requests that are being sent backwards and forwards to the server. The two headers can be used interchangeably depending on the server configurations. You can use burp turbo intruder to test and see this in action.   

What’s the impact?

By smuggling an additional request into one , you can bypass security controls that are in place and potentially access/modify how the back end will send a response to another request/user. This can be used from anything to fetch etc/passwd, send redirection links, or even takeover accounts which was shown on Slack.

How can I detect it?

There are numerous manual tools that have been made for testing Request Smuggling vulnerabilities, such as Burp Suite’s smuggler extension or Gwendal Le Coguic’s smuggler py.

Disposable mail can also help. You can test for this directly within Disposable mail by activating this beta feature within your scan profile settings. The findings will show you where in the application it was found, and provide remediation tips to prevent future HTTP request smuggling attempts.

How can you remediate it?

  • Ensure the same server software is used on both the front and back end servers so they agree which header they will use will prevent the conflicts (either Content-Length or Transfer Encoding: chunked).
  • Some WAF providers already have built-in mitigation when they detect abnormal requests. Check with your provider if they have support for this
  • Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.

Special thanks to:

Disposable mail checks whether your web applications are vulnerable to HTTP request smuggling and other common attacks. Sign up for Disposable mail with a free trial today and check for 2000+ common vulnerabilities beyond the OWASP Top 10.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Phishing Attacks Can Now Dodge Microsoft 365’s Multi-Factor Authentication – Disposable mail news

Of late a phishing attack was found to be stealing confidential user data that was stored on the cloud.
As per sources, this is the work of a new phishing campaign that dodges the Office 365 Multi-Factor Authentication (MFA) to acquire the target’s cloud-stored data and uses it as bait to extract a ransom in Bitcoin.

Per reports, researchers discovered that the campaign influences the “OAuth2 framework and OpenID Connect (OIDC) protocol”. It employs a malicious “SharePoint” link to fool the targets into giving permission to “rogue” applications.

MFAs are used as a plan B in cases where the users’ passwords have been discovered. This phishing attack is different because it tries to fool its targets into helping the mal-actors dodge the MFA by giving permissions.

This campaign is not just about gaining ransoms via exploiting the stolen data it is that and the additional threat of having sensitive and personal information at large for others to exploit as well. Extortion and blackmail are among the first things that the data could be misused for.

Sources mentioned that via obtaining basic emails and information from the target’s device, the attacker could easily design “hyper-realistic Reply-Chain phishing emails.”

The phishing campaign employs a commonplace invite for a SharePoint file, which happens to be providing information regarding a “salary bonus”, which is good enough for perfunctory readers to get trapped, mention reports.

The link when clicked on redirects the target to an authentic login page of Microsoft Office 365. But if looked on closely, the URL looks fishy and created without much attention to detail, thus say the security experts.

Reportedly, access to Office 365 is acquired by getting a token from the Microsoft Identity Platform and then through Microsoft Graph authorizations. OIDC is used to check on the user granting the access if authentication comes through then the OAuth2 grants access for the application. During the process, the credentials aren’t revealed to the application.

The URL contains “key parameters” that explain how targets could be tricked into granting permissions to rogue applications on their account. Key parameters signify the kind of access that is being demanded by the Microsoft Identity Platform. In the above-mentioned attack, the request included the ID token and authentication code, mentioned sources.

If the target signs in on the SharePoint link that was delivered via the email they’ll be providing the above-mentioned permissions. If the target doesn’t do so, it will be the job of the domain administrators to handle any dubious activities.

This phishing campaign is just an example of how these attack mechanisms have evolved over the years, to such an extent that they could now try to extort sensitive data out of people seemingly by tricking them into providing permissions without an inkling of an idea of what is actually up.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Undetected e.02 recap: Fredrik N. Almroth – Bug Bounties – 10 minute mail

Bug bounties – some argue that this is one of the buzzwords of the decade in the cybersecurity industry. Whatever you want to label it, it’s a trend that we can’t ignore these days. A lot of companies are taking part in it, so what’s it all about? 

There were many valuable soundbites to take from this, and especially from podcast guest, Fredrik N. Almroth (@almroot) because he’s hacked all the tech giants and more. If you can name it, he’s probably hacked it. We’ve taken highlights from this bug bounties episode, and the dialogue has been edited for brevity. Let’s dive in:

Disposable mail Co-founder and security researcher Fredrik Nordberg Almroth

Image: Fredrik Nordberg Almorth, Disposable mail co-founder and world-class bug bounty hunter

Undetected – a web security podcast is a Disposable mail production that uncovers different depths of web security. You can listen to the full length of Episode 2 on SimpleCast or your preferred podcast platform. The video version is also available online.

Fredrik and his take on the evolution of web security

Fredrik: Well, I’m a security researcher and co-founder of Disposable mail and… I hunt for bug bounties, which kind of correlates to how we do things in Disposable mail. I started already in high school … when I met my fellow co-founders of Disposable mail. By that point we realized that, well the Internet is quite broken. This was back in 2006 when we first met and by 2008, we decided to start a consultancy business doing penetration testing. But one thing led to another and we started automating things and this idea kind of grew. So we all went to university and dropped out one after another. And by this point, some ideas started to stick, like crawling is pretty good to find your URLs on the website and if you have query parameters in URLs then you can start looking for SQL injection.

Then Cloud started becoming a buzzword around here in Sweden. So we figured why not make a new company doing something else.

Laura: We have taken quite huge strides when it comes to security in these past few years as well. How do you feel that automation, for example, played into this?

Fredrik: You can say that some vulnerabilities come and go, SQL injection was a lot more out there a couple of years ago, but now it’s mostly been abstracted that way by different frameworks and so forth. But at the same time, you now have like server-side template actions, and it’s basically the same kind of injection attack state. 

They come and go, but in different forms over the years. Now there’s more out on the internet, more services, more technologies in general. There are more things, hence more things can break, but at the same time, the vulnerabilities that exist back then, are not as common nowadays except for XSS.

Laura: It (web security) really evolved and the hacks in general. The Tesla hack you did was a cross-site scripting attack. Right?


Fredrik: Tesla was running Drupal at the time, and Drupal was bundled with a “what-you-see-is-what-you-get” kind of editor called CK editor, and this library bundles with an example file. So using this example file you could do a drag-and-drop XSS where you can drag something that looks okay on one website onto some other place, and it executed in Tesla’s origin… And then you have cross-site scripting – Tesla DOM DOOM XSS. So what I demonstrated was you could play Doom on Tesla’s website, and I replaced the entire window with the game Doom.

Laura: That sounds like fun. Couldn’t play Doom anywhere else?

Fredrik: Yes, it’s, well I packed away this payload because it was fun. So I use it every now and again in various cross-site scripting demonstrations.

Getting read access on Google

Laura: Also a bigger vulnerability that you found previously was back in 2014 when you found an XXE vulnerability in Google. Basically you were able to run your own code on Google’s server. 

Fredrik: While the company wasn’t low on cash yet, Mathias Karlsson (a co-founder) and I figured that bug bounty actually works as a way to collect some money. So what’s the most bang for the buck? What companies are out there that we can hack and get the most money for the least amount of effort? Facebook or Google.  

Well, Facebook is not very fun to target, so we went for Google. Our approach was: we should find the newest features and products or go for the really old legacy stuff that they might’ve forgotten. So using Google search itself, we found a feature that dated earlier than 2008 called the Google toolbar button gallery. So if you remember this way back in the Internet Explorer, you had this toolbar from Google and companies could upload their own buttons to this toolbar and that was the feature we attacked. This was an XML file uploaded to Google.

You as a website owner could add your own button to the toolbar so that other users could find you. This button definition was an XML file and quite frankly, you can do a lot of weird things in a plain vanilla XML file, and an external entity is one of those.

Fredrik: We uploaded a file and gave it some name and description, etc, but we added a definition that instructed Google to try to read another file from their local file system. So we tried to pull the normal user file on Unix systems and uploaded it and it worked. But we asked, “Okay, did anything actually happen?” 

We made another attempt where we changed the title to something like “hello world”, and then searched on Google or for toolbar buttons containing “hello world.” … meaning we searched for what we just uploaded.

Laura: That’s kind of like local file inclusion.

Fredrik: Yeah, that’s basically the impact. We got read access on Google.com. This was quite fun. So from start to stop, it took us four hours to identify, exploit and have it reported.

Start of bug bounty career:

Laura: Were these all bug bounty programs or were they public programs that you enrolled in or how did you stumble across these?

Fredrik: This was about the time that we actually founded Disposable mail and bug bounty started becoming something you spoke about on Twitter. So Google, in my world, was the first company I saw that had this kind of policy, meaning anyone can hack Google. If they manage to do it and Google accepts it as a new unique vulnerability, you get money for it and afterward, you can speak about it. As an early-stage startup, this was nice to have some material to be seen and heard.

Laura: How did people react to your work on bug bounties back then?

Fredrik: It varied. People in Silicon Valley know about this as that’s kind of where this entire industry started. But over here in Sweden, it was unheard of that this was even a possibility. For example, a friend’s friend of mine happens to work for the Swedish Police and I told him about the Dropbox hacking event which I attended in Singapore, and his response was, “What? You can’t do that? That’s criminal.” I said, “No, no, no, you missed the point.” I had to elaborate a bit on what bug bounty is and so forth.

Laura: In our bubble of Infosec, everyone knows what a bug bounty is or what responsible disclosure is, but outside of this immediate bubble, it is not that obvious. What is your short description of bug bounties?

Fredrik: Bug bounty is freelance penetration testing in a way. Anyone on the Internet can go to a company, find a vulnerability and have a streamlined process of reporting it to the company. If it’s a unique vulnerability and you are the first one to submit it, then you get a monetary reward at the end. Now we have platforms and marketplaces to facilitate this among vendors and researchers such as Bugcrowd, HackerOne and Synack.

Laura: Yes and bug bounties are offering a [monetary] reward in exchange for the vulnerability report or swag.

Responsible Disclosure Policy – that’s all it takes:

Laura: These bug bounties have basically lifted hackers out of the darkness, and now hackers can actually talk about what they have found. They can disclose it, depending on the program. It’s also shedding a more positive light on hackers.

Fredrik: Indeed. But I think it’s quite important to speak a bit about Responsible Disclosure programs as well, since it’s basically the first stepping stone to do something like this. It could be as simple as having an email address or a contact form where someone can submit vulnerability information. That’s all it takes.

More often than not, you (an ethical hacker) know it yourself that there are vulnerabilities all over the place, but it can be quite tricky to report it.

And you (application owner), you don’t always have to offer swag or money. You just have a channel to accept it.

Laura: A common practice out there is putting a security.txt file in your domain so that people find the contact information of your security personnel there for reporting.

Is this the minimum thing that a company should do in terms of Responsible Disclosure?

Fredrik: Security.txt is a very good starting point. With that, you can set up a [email protected] email (to receive reports).

Laura: So you don’t need to go on a commercial bug bounty platform and open a program there?

Fredrik: No, I think that should come a bit later once you have matured your security processes, so you know what you get basically. It can be quite overwhelming if you go directly to one of these platforms, open a bug bounty publicly to the world because everyone will start reporting straight away.

Laura: Do you think that a company who enlists in a public program will get a ton of reports right from the get-go?

Fredrik: More in the beginning, and then it should probably slow down.

Laura: Would it make sense then to do some kind of security assessment before that?

Fredrik: Yes. I think you should only start with a Responsible Disclosure Policy. 

Once you’ve had your pentest reports, some automated scanning and an organization that can handle the security reports, then you should consider a Responsible Disclosure Policy or a private bug bounty program. After that, you could make it public.

Laura: Do you feel that offering a bug bounty program is appropriate for all sorts of companies out there?

Fredrik: Yes, I think so as long as you have some kind of online presence. But it has to be something technical. It’s quite hard to have a bug bounty otherwise. Even manufacturers of hardware, for example, are growing with IoT applications. These could open up as bug bounty programs.

Laura: Yeah. I’m just trying to think of something that wouldn’t have an online presence these days.

Fredrik: But Everything has, right?

Laura: Yeah. Everything has at least a company website, if nothing else.

Fredrik: Exactly. You always have something important to your business and you can probably make a bounty program around that. Ask yourself what you are trying to protect. Say you are Dropbox. The most sensitive things would be your users and their files, right? If you’re Apple, well, it’s basically everything, that’s a bad example I guess. For a bank, it’s probably the money.

So then it doesn’t really matter if it’s only one domain. That’s the scope for your program. You should really try to think about this, “what am I trying to protect?” and make a policy thereafter.

Setting the scope of your disclosure program:

Laura: You mentioned “Scope”, and the scope in a bug bounty program is defined by the company and it can be a domain or source code or some device.

Fredrik: Yes, it’s usually along those lines. It’s one or several domain names that can be mobile apps, GitHub repositories, etc. If it’s a hardware manufacturer, it could be their devices to sell to consumers. There are a lot of blockchain companies that would be attacking the blockchain technology itself.

Laura: What is the best scope for you as a bug hunter?

Fredrik: For me privately, the bigger scopes the better. Being a security researcher, you have a bit of an arbitrage. The more things that are exposed and that you can audit, the more things will break, as simple as that. The bigger the company, the easier it is in my opinion, and that’s because a bigger scope means more critical vulnerabilities and that’s more business impact. So it will help you as a company even more.

Laura: So what happens if you go outside of a scope in a bug bounty program?

Fredrik: That really depends on the organization. What really matters in a bug bounty program is the business impact that an outsider can have. So unless something is explicitly out of scope, it could be fine to report a vulnerability if it has a proven impact.

That’s my take on it. Although that could also be considered scope creeping if you do this.

Laura: What is scope creeping?

Fredrik: You go a bit out of scope and in again. For example, if you find something on Adobe and you go outside to some local subsidiary or something and then back into scope. More often than not, it’s generally accepted on these live hacking events. 

Laura: Maybe at the live hacking events, the overall environment is easier to control than hacking otherwise.

Fredrik: In these events, they collect a group of people to hack a company over a day or two in person. Then you have all the stakeholders at one place they can communicate about it.

Laura: Do some security researchers not report something if it’s out of scope and if it’s not that critical?

Fredrik: 100%. I really believe so. For example, Open Redirect is no longer on the OWASP Top 10. Finding an open redirect somewhere on a subdomain that might be explicitly out of scope and while you know it’s there, you wouldn’t report it with the risk of losing a score or a reputation or what-not on one of these platforms.

But at the same time ,if they have Oauth and misconfigured, I can use it to do some kind of authentication bypass or steal some sensitive tokens. Then all of a sudden you’re out of scope, then go in again, and you might have an account takeover and that would be usually considered critical.

And that companies would accept.

Laura: So it really depends on the impact and if you can demonstrate the impact.

Fredrik: Exactly. That’s, I think that’s the moral of the story. It’s the impact that matters. You need a proof of concept. Otherwise it’s kind of a void report.

Laura: Yeah. Because I used to work as a pentester and during an assignment you have limited time as well, so you don’t always have to provide the proof of concept. Pentesters look at it from a wider angle and they can see white box, the infrastructure, the servers and so on. So for me, it’s interesting how impact-driven the bug bounty community is. It’s a good thing.

Bug bounty is a growing industry

Laura: Bug Bounties have become a big industry but it has also gotten some criticism or scrutiny over how many active researchers there actually are, like this Dark Reading article by Robert Lemos on how bug bounties continue to rise. But the market has its own 1% problem

It’s kind of like the same as being a professional in anything, like a professional basketball player. And I think that was also something that was said here in Lemos’ article that was most likely a quote from Mårten Mickos that not everyone is going to succeed. And then there’s a group who succeed are really, really good at what they do.

Fredrik: Right. A lot of people are drawn into what they see on Twitter and the media that bug bounty is a growing thing. People go around on these live events where it’s an open environment and everyone always finds something critical, which is true. But to get there, that’s the hard part.

A vast majority might not have a professional take on how to report vulnerabilities, and then it might be people like yourself coming from pentesting background without experience on the same style of reporting.

Laura: … And having all of them rejected.

Fredrik: That’s the thing, right? If you go in with the mindset of a pentester, then I don’t think you would grasp it well, and it probably would be a bit discouraging. And once you get the grasp of it, then you need it to beat the rest that are in the game with vulnerabilities that will be accepted. So I think it could be a steep curve to get into.

Laura: You have been active since 2013 so you’re well ahead of people who are only starting out now. What are tips you have for beginners when trying out bug bounties?

Fredrik: Learn by doing. Submit reports and see how it works, and when it works. There are a lot of good resources out there and streamers that speak about how to do bug bounty, and educate people on what to look for.

Laura: What do you recommend?

Fredrik: I’m going to be a bit biased here, and recommend our fellow coworker, TomNomNom. I also like STÖK, a Swedish researcher.

Anything that Bug Bounties aren’t good for?

Laura: What is something that bug bounties are not really good for?

Fredrik: It’s not a silver bullet to your security. It’s a nice addition to an already quite mature organization in terms of security. It’s the many-eyes principle meaning you have more people looking and trying to break something – and someone will eventually be able to do that. 

If you start a bit premature with doing bug bounties as a company, chances are that it will be a bad experience for researchers. For example, it sucks for me if I report a vulnerability and it gets flagged as a duplicate. I’m probably not the first one to be flagged as a duplicate.

Laura: Or if the companies are slow to respond?

Fredrik: Yes. It must be horrible for the company as well. They get an overwhelming amount of reports as they can’t act on it fast enough, so then it’s not nice for anyone.

Start with private and then slowly expand the scope and amount of people that participate in your program and have it as an addition.

Laura: It’s a good way of getting rid of those low hanging fruit and understanding what you’re exposing there?

Fredrik: No, on the contrary. The bug bounty community will find all of it. They will find the XSS’s. If you can’t fix the XSS fast enough, then you will have a problem.

Laura: You will have multiple reports on the same XSS.

Fredrik: Yes, you will. The best researchers tend to go for more creative vulnerabilities and you want them to be looking deep into your system and catching hard-to-find things.

Laura: Do you think that all companies get equal treatment from bug bounty hunters as well?

Fredrik: No, I don’t think so. It’s absolutely a monetary interest. There are more and more companies joining these platforms, and there’s a limited amount of researchers that provide value. So then you have to compete with other programs to have researchers look at your stuff.

Researchers like big scopes

Laura: We’ve had multiple takeaways for our listeners in this episode already, but do you have any like one big takeaway for our listeners?

Fredrik: If you’re a company, start small, then expand. Researchers love big scopes, so try to reach that eventually. 

If you’re starting off with bug bounty hunting, don’t give up too soon. It takes time and practice to get into this, but it’s not impossible. Anyone can do it. Really. It’s just problem-solving.

Did you like the highlights of this episode? Check out the full episode in the web player. It’s also available on Spotify, Apple Podcasts, Google Podcasts or another preferred podcast platform.


Keeping up with the fast-pace of web security is a challenge if you are only relying on standard CVE libraries and annual security checks. Disposable mail works with some of the best ethical hackers in the world to deliver security research and modules from the forefront of security, so you can stay on top of emerging threats. Interested in giving Disposable mail a go? Start your 14-day free trial today.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Disposable mail security updates for 16 April – 10 minute mail

For continuous coverage, we push out major Disposable mail security updates every two weeks, keeping our tool up-to-date with new findings, features and improvements sourced from our security researchers and Crowdsource ethical hacker community. Due to confidentially agreements, we cannot publicize all security update releases here but they are immediately added to our scanner and available to all users. This post highlights a few things that we have improved in the last two weeks.


CVE-2020-7961: Liferay Portal Unauthenticated RCE

Liferay is an enterprise portal that allows the use of corporate extranets and intranets. Most recently, a JSON Object deserialization issue has been found that would allow an attacker to execute arbitrary code. 

The vulnerability is described further here: https://codewhitesec.blogspot.com/2020/03/liferay-portal-json-vulns.html

Adobe AEM Flush Dispatcher DoS

An interesting report was submitted to the Crowdsource team that showed a very simple way to invalidate or flush cached pages without any rate limiting in Adobe Experience Manager. If done repeatedly, this can lead to Denial of Service attacks.

CVE-2020-8509: Zoho ManageEngine Desktop Central Unauthenticated PDF Servlet Access

Zoho ManageEngine Desktop Central is an endpoint management solution that helps to manage servers, laptops, desktops, smartphones, and tablets from a central location. A Crowdsource researcher, is credited with finding an unauthenticated servlet access vulnerability, which allows unauthenticated users to access PDFGenerationServlet, that can lead to sensitive information disclosure.

Questions or comments on the latest Disposable mail security updates? Let us know in the comments below.

Begin a scan for the latest vulnerabilities today. Start a free trial with Disposable mail here!

Already have an account? Login to check your assets.

Disposable mail is a continuous web vulnerability scanner service and we release Disposable mail security updates at least bi-weekly. Disposable mail offers a crowdsource-powered testbed of 1500+ known vulnerabilities including the OWASP Top 10. Check for the latest vulnerabilities!

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Meet the team: Tom Hudson – Collaboration is the way forward – 10 minute mail

Some know him by his hacker handle, TomNomNom. UK-native Tom Hudson started at Disposable mail as a Senior Security Researcher, and he is now the Tech Lead for Security Research & Module Development on the Crowdsource team.

His passions include fixing and reshaping most things from software to furniture and spending time with his two kids. He also values collaboration, and this has played a significant role in his journey going from software engineering to ethical hacking:

Photo of Tom Hudson aka TomNomNom

Image of Tom Hudson, Tech Lead for Security Research at Disposable mail

Somewhere in Yorkshire

Tom lives in Yorkshire, the UK, somewhere near Leeds. Since he was a kid, he wanted to become an inventor and he found that becoming a software engineer was a better choice, since he could meet his interest in creating something new, without the cost of raw material. Hence, he studied Electrical and Electronic Engineering at Bradford College and started his career as a network engineer. 

Over a decade has passed since then and Tom now carries a heavy backpack of experience that encompasses everything from DevOps and Solutions Architecture to People Management and Training. 

A passion for fixing things and giving knowledge

Tom has a collection of over 1000 tools and spends most of his time in the garage reshaping objects or fixing some of the toys that his 4- and 6-year-old kids damaged while playing. Fixing broken things has become more of a job since he started his career in Development and therefore, in search of a new hobby, he stumbled across training and education. “I have a passion for learning and finding out how things work,”  he says, “that is maybe why I thrive the most in a training role.”

Besides fixing tools and toys, Tom is passionate about learning new things and he feels the urge to share this knowledge with others as a trainer:

“The good thing about having a training role is that it pushes you to be better at conveying complex topics in accessible ways to a varied audience. The feeling I get from giving others tools to learn by themselves is truly rewarding.”  

From Network Engineer to a Hacker

Tom started his career as a Network Engineer at a small company that provided Information and Communications Technology (ICT) support to local schools. He was already interested in Cybersecurity then but never imagined that being an Ethical Hacker would be his full-time job one day.

His first hacking experience arrived when a former employer invited all employees to hack their system to help find vulnerabilities and breaches. This experience landed him on the HackerOne (a bug bounty platform) scoreboard and he was suddenly invited to different hacking events. 


As he got introduced to the bug bounty community, he realized that his previous knowledge as a Software Engineer was extremely valuable as he could use his competencies to build new tools and automate his hacking processes. This was received with a lot of curiosity by the community who started to follow him on different bug bounty platforms. The more connected he was with the community, the more he started to collaborate with other ethical hackers and build more automation for finding security flaws.

His ability to build these tools and share knowledge with other members has led him to many high-payout findings and interesting collaborations. In 2019, Tom landed one of the biggest bounties at Hackerone’s H1-4420 and won the title of Most Valuable Hacker and later led a workshop on Cybercrime with the local police.

Changing the narrative

Collaborating with the local police has made Tom better understand the need for education in cybersecurity and for a different tonality when talking about hacking.


Sometimes things concerning cybersecurity are legitimately scary. But I think that many marketing campaigns are trying to constantly push for a narrative that creates fear around the topic of cybersecurity. This is pushing people away, as there are a lot of misunderstandings.” 

He believes that the future will bring more bugs and breaches, but hopefully, also more scanners, more software and ultimately, more ethical hackers. He says it feels like the Internet is mature but, in reality, there is a lot of room left for growing and discovery.

Tom believes that, as high-profile data breaches will become more common, there is an increasing need for changing the narrative when speaking about them and hopes that governments will recommend open corporate responsibility disclosure programs. He says, “some governments have already started doing so, and this might reduce the perceived shadiness that hackers and cybersecurity are associated with.

The importance of diversity

While there have been interesting improvements in how people and governments understand cybercrime, Tom also acknowledges that there is still a lot to do. In particular, he believes that the cybersecurity industry needs more diversity alongside collaboration.

He says: 

“I sometimes feel like people who don’t happen to be white and male might have a more difficult time getting started in the community and I believe that especially in such a complex field as cybersecurity, diversity is incredibly important. Monocultural teams so often fail to consider cases that are important to many.” 

Tom mentioned that one of the aspects that were highly interesting about Disposable mail was diversity:

In the past, I’ve found it difficult to drive diverse thinking in my teams. At Disposable mail, it happens naturally, thanks to the gender and nationality balance.

Disposable mail – a diverse place for sharing

We asked Tom for other reasons for joining Disposable mail and he revealed his motivation to join a company that is aligned with his values of diversity and provides others tools to learn for themselves. 

He explains:

At Disposable mail, I can be part of the Hacker School project, which is a session in which we teach our customer-base, some of which may be non-security experts, about cybersecurity and give insight into the mind of a hacker. Sharing knowledge is at the core of Disposable mail’s values and products, and being part of the team means that I get to share what I know in different conferences but also within the team.” 

Tom talks about the allocated Knowledge Sharing sessions that are organized by employees at Disposable mail, where members of different teams get to share their work, passions, and hobbies with the rest of the organization.

He adds:

“On top of that, the Disposable mail team seems to be aware of the importance of work-life balance and mental health. The people here are people, not just workers and it is humbling to work in such a human environment.

From a technical perspective, Disposable mail poses a whole new challenge for me as what we are doing is super interesting and fun stuff. It feels like I have a constant influx of new things to learn!” 

The way forward

Moving forward, Tom suggests that we should lead with these values and try to be more collaborative with other companies in the industry.“We should take the community spirit to businesses,” he says, “and collaborate with our competitors or companies in the cybersecurity industry”. 

Tom believes that more collaboration in the cybersecurity industry will be beneficial, “instead of looking at each other as competitors, we should enable each other and work together to fix the complex world of the internet.”

Quick Q&A with Tom Hudson

Mac or PC? A PC running Linux.

Android or iOS? Android; the closer to stock, the better!

What’s your #1 security tip? Don’t reuse passwords and do enable two-factor authentication.

How do you keep up-to-date with tech and business? Mostly through following interesting people on Twitter.

What’s your favorite Disposable mail blog post? Bypassing and exploiting Bucket Upload Policies and Signed URLs


If you are ready for a new challenge to bring a more collaborative spirit to web security and work with top-ranked ethical hackers like Tom Hudson, take a look at our open positions to join the teams in Stockholm or Boston! 

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Top 12 tips every pentester should know – 10 minute mail

In 2020, both big and small companies alike are embracing pen-testing as a solution to ensure the quality and availability of their mission-critical communication systems and data storage. 

Disposable mail Crowdsource is our private bug bounty community that’s powering our automated web security scanners to protect 1000s of security teams. It’s true that bug bounty hunters and pen-testers are not the same breed yet we see a lot of our hackers learning new skills to break into the pen-testing scene, and help keep out hackers with hats as black as ink. 

Disposable mail security researcher, Fredrik N. Almroth and his thoughts on the growing interest for pen-testing:

“As a researcher, I see a lot of mistakes that can be avoided out in the wild such as unauthorized access to things in the supply chain and obvious tampering marks in the data. Year after year, companies have 2 options with pentesting: they can be proactive with testing business assets, or react once everything suddenly breaks at once. If you have the resources, bringing in pentesting can help companies stay on top of risks and get results before the ink is even dry on the auditing contract. “

While there are differences in what they do, there are also a lot of similarities. So we asked the Disposable mail Crowdsource community, some who’ve even hacked the Pentagon, to share some of their top-paying tips that every great pen-tester should know:

robot technology GIF by Banggood


There you have it, some top-paying pen-testing tips from Disposable mail Crowdsource hackers. Now it’s time to get out there and get your next gig. Happy pen-testing!

Get A Job Hackers GIF


Are you interested in joining our community on Disposable mail Crowdsource? Learn more at https://cs.detectify.com/

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Undetected podcast e.01 recap: The evolution of web security and hacking – 10 minute mail

Web security is like an onion, or maybe the deep sea, where there are depths to be uncovered. This is precisely what Undetected – a Web Security Podcast by Disposable mail is set to do. Our new podcast series is hosted by Disposable mail Security Researcher, Laura Kankaala. Each session, she invites a guest speaker to discuss some common security topics from another perspective, and other topics that may not have ever crossed your mind.

Undetected - a web security podcast by Disposable mail artwork

In the pilot episode, Laura is joined by Disposable mail co-founder Johan Edholm. He co-founded the company back in 2013, and is still involved with the organization today by managing the technical infrastructure in the clouds. We don’t want to give away too much, but there are some things said that are just too good to not be highlighted and we’ve summarized of some of the conversation:

This episode discusses the evolution of web security, and starts off the discussion on its current state by first going back to where the Internet began for them. Both Laura and Johan are from the same generation, yet their first experiences with the Internet differ.

Guest speaker Johan Edholm (left) and Host Laura Kankaala (right)

Do you remember when your first interaction with the Internet was?

Johan: I remember in the early days we didn’t have the fast Internet connection we have now. Actually, we weren’t even allowed to use computers, really, at home. My dad’s a farmer, and he believed you should work with your hands, and computers are bad… It was very different, everything was slow and taboo, I guess.

Laura: I remember when we got our first computer… it was more like, everyone got to use it. We didn’t have it online but my sister and I used to play a lot of video games.

Johan: We were not really allowed to do that, because dad had his tax documents on the computer and he would say, “Oh no, you’re going to get a virus, and everything is going to be terrible.” We weren’t allowed to touch it. When he was out working at the farm, I actually snuck to his computer anyway, and used it. I remember having to print out into text files to read offline.

Laura: My first experience was with making websites using Geocities, a hosting platform for websites. I also had my first hacking encounter here: my friend’s website was hacked and the person just changed the wallpaper on the website. I thought, “oh, is this hacking? Wow. Who would ever do this?”

When did you first experience hacking or web security?

Johan: IRC was a big part of my early time on the Internet, and security. I got into security fairly quickly, when it came to IT. I wasn’t much of a casual Internet surfer… but I’ve always been interested in this magic kind of thing. Before that, it was more literal, the sleight of hand and illusions. I think hacking has the same feeling. If someone does something that’s out of this world, I want to understand how the fuck that works. It annoys me when I don’t. That’s when I started to look into it, and that was fairly quick into this whole Internet journey, I guess.

I read a lot of those magazines, or similar texts where people were talking about hacks, and I guess those were probably the earliest experiences of things being hacked, without me actually seeing it for myself, just reading about it.

What about phreaking?

Johan: Back then, hacks were mainly teenagers pranking, and phone phreaking was a big thing because way back you didn’t have the Internet, but you had phones. Maybe you wanted to call someone, and it was really expensive so people wanted to bypass that. If you read Kevin Mitnick’s book, Art of Deception, he uses it a lot when he’s doing other shenanigans like social engineering.

Laura: Yeah, Kevin Mitnick is probably one of the OG hackers out there.

Johan: He’s definitely one of the most famous, at least. He was chased by the FBI, and was on their top wanted list for a bunch of years. He has written a lot of books regarding social engineering, and security in general. And I’ve read Art of Deception myself. It was a long time ago, that was in my early, early days of security, I’d say. But that one is fairly good when it comes to social engineering. 

How did the industry look when you started working with security?

Johan: In 2008, myself and the other founders turned 18, so we could actually register our first company. But I think it started 2007, just not too serious. We were just nerds, trying to build something because it’s fun.

Laura: What was the initial thing that you were working on?

Johan: It was the same scanner as we’re having now [in Disposable mail]. We wanted to automate security. Back then, the idea was to maybe be consultants since that was what everyone was doing, so it seemed like an easy thing. But then we’re lazy, so we figured we could just automate. Might as well, right?

Then, this whole cloud thing was growing, and I guess we were early jumping on that train.

Laura: Nowadays, we have: bug bounties, consultants, pentesters, a lot of people working in this field and it’s constantly growing. How was it back then in 2008?

Johan: How I remember it was that security people were mostly consultants. Of course, you had these security products, but generally, things moved slowly and were enterprise-y. Security was very much a product for the enterprise and for people with money. It’s not like a 10-people company would hire a pen tester. That’s usually very expensive.

Also, the vulnerabilities you saw were simpler. It’s getting more and more complex now with bigger systems. You need to find flaws in how they interact with each other. Back then, it was often quite straight forward. I think that’s a symptom of this: few people that could afford security. 

Bug bounties weren’t a thing then. I know Netscape had one around ’95, but nobody knew about it. Or, at least I didn’t. That’s not web. It was the browser, not the Internet itself. The whole feeling around it was very different.

Laura: What were the top three vulnerabilities at the time?

Johan: My feeling is that it was mostly SQL injections, those were very common. They had a very large impact. They, of course, are still around a bit today, but it’s much, much more rare. Back in the days, those were everywhere.

Then, remote code executions, they were, compared to now, much more common. It’s very basic. Now, you have SSRF, rather, which is the new RCE, almost.

The third? I would say file inclusions, like local or remote, even. They were fairly big as well, if you count the impact.

One thing that’s stayed is XSS. These vulnerabilities might have changed shape, but are still around, and probably even bigger now.


RCEs today:

Laura: What you said about the RCEs and and comparing them to SSRFs is interesting in that you think they are the new RCEs.

Johan: That’s more or less what we see nowadays. When you get that impact, it’s usually not the standard RCE. Before we could really have RCE in a query string, like in the URL.

Now things are much more complex, so you use the complexity of an application against itself. It makes things really hard to detect, I think, as well. Or, harder at least, to detect those kinds of things often.

What about Hacktivism?

Laura: One thing that I feel has changed, also, over the years, is the role of hacktivism.

Johan: Yeah, I think so too. I would attribute that, partly, to bug bounties. Now, people have a legal alternative to make a lot of money, even, on hacking. Back in the days, people wanted to have fun. Pranksters or teenagers were defacing websites, or changing the background and look of a website, to spread a message, or just because they were bored.

Laura: Yeah, it feels like, back in the days hacking was more political. Hacktivism basically stands for having some kind of political agenda, or some kind of bigger agenda behind hacking. For example, collectives such as Anonymous.

Johan: Yeah, that’s my impression as well and maybe they’re just more careful or hidden. Maybe they do a lot of things behind the curtains that we don’t see, and they could, for example, dump things to Wikileaks.

Back then, people really wanted to make a name for themselves, as well, often tagging releases with the group name, like Anonymous. There was also Lulzsec, that was fairly big in this. I’m not sure if they had much of a political message, to be honest, but at least they liked to tag it.

Going from hacktivism to bug bounties:

Laura: I think bug bounties have made a difference for individuals when it comes to security, because now they have a platform for reporting these things as long as they stay in scope, and work accordingly to the agreed rules and policies in there.

Johan: People often hack for the challenge. Now, when they have a legal alternative to it, they can brag about it on their high score lists rather than having to deface a website, and write their name on it. They have a more ethical alternative, which is very good.

Hacktivism is not completely dead:

Laura: Hacktivism is not completely dead, though. For example, just recently, a hacker going by the name of Phineas Fisher announced a bug bounty program for hackers, basically.

Johan: That was also delivered as one of those pure text files, that are very popular. I read it, and it brought a lot of nostalgia, to be honest. That was a very strong political statement, and something one often saw, I think before our time. I’m born ’90 and I think that style was more common in the ’80s. But the message that’s in that is a lot like, “Fuck Capitalism.”

Laura: For example, this is a quote from that manifesto. They said that, “Hacking to obtain and leak documents with public interest is one of the best ways for hackers to benefit this society.” I think this is an interesting message. Naturally, I think it’s not that outdated, but when it comes to Responsible Disclosure, or Bug Bounties, these kinds of ideas don’t typically come out in bug bounties. Rather they never, because in bug bounty programs they ask you not to leak information, or to responsibly disclose the vulnerabilities that you find.

Johan: We might call it responsible disclosure, but I guess, the hacker in this case would not call that responsible… This hacker claims to be a she, so I’m going to refer to that. She says rather, how to best benefit society by leaking documents, etc. I guess it’s very subjective, what’s responsible in that case.

Laura: Absolutely. They are also offering up to $100,000 for hackers who are able to leak some kind of documents. I don’t know where this money comes from, but they are paid in Bitcoin or other cryptocurrency. I consider this hacktivism when one is asking for these kinds of leaks.

Becoming IT security professionals:

Laura: We are both working as professional security people today. When I was studying, for example, it never occurred to me that I could be a pentester. Only when I entered the IT field, and I worked as a SysAdmin for a bit, was I able to change to a pen tester role. Only then I understood that, okay, this is actually a career, and you can make a career out of this.

I think you had this realization much earlier than I did, because back in 2008, you were already in this line of work.

Johan: My dad’s a farmer, he worked with his hands, and his dad was also a farmer, on the same farm even. On my mom’s side, they were plumbers. So, for me, I never saw it as a possibility to work within the IT field. That was something you did as a hobby, like playing chess or something.

I remember when that clicked for me, it was when I saw there was a school that I actually ended up going to, an IT school here in Stockholm. I was like, holy shit, you can actually work with this? Is that a profession? I had never accepted that. All the way until 2007, or 2008, it wasn’t that big, you didn’t hear that much about it then. I’m not sure if I really realized that security specifically could be a profession for me, either.

I honestly wasn’t even sure if I wanted to work with IT. It was more like, I think it’s fun, and I find it fairly easy. But, do I want to have this as a profession or as a hobby?

Shifting everything to be online:

Laura: A lot of our lives are actually happening online. We have social media, we have our banks, our health, everything is online. It has also become more profitable to hack into these things, also for personal gain. If you are a malicious actor, and you are able to hack into a company, or steal data from them, that can be directly profitable for you, if you sell that data on illegal marketplaces.

Johan: Yeah, exactly. I’d say, further back people mostly had websites to show where they had their store, maybe. Now, you have the store online, and you have all the user records there: who buys from you, and maybe even their history, etc. All that can be valuable for some people. If nothing else, it could be useful for doing other attacks, like spear-phishing attacks (scamming people by stalking them) which make these kinds of scams much more successful.

You have a higher incentive to actually hack things. You don’t have to go through your house to break in to look at them, you can do it overseas. It’s a very easy way to be a criminal as well, I guess.

Do you feel that the security landscape is getting better?


Johan: Yeah, I would definitely say it is, actually. We’re getting better at both defense and offense. It’s harder now than it was 10 years ago to get into a fairly good security level. Because we have evolved, you have to understand more things, and you have to work your way to patch a lot of the common problems. There are a lot of frameworks that, by default, aren’t vulnerable to SQL injections.

When you use frameworks, one patch can fix a lot of things, and I think we have been fairly good at that, by raising the security awareness. Of course, there are still a lot of good hackers, and you can still make mistakes, but I would say it’s better now.

Laura: More on that, the frameworks already have these built in mechanisms to mitigate this, they filter the input or the output that comes to or from the web application, so that using those web applications is more safe for end users today.

Johan: We have learned by our mistakes, and switching it to be safe by default. If you have some edge case where you don’t want that kind of security mechanism for some reason, it’s an opt-out, rather than opt-in. I think that’s really the change we have seen, and that we will hopefully continue to see.

Laura: Today there are a lot more tools that can provide automated security. And there are also consultants, and a lot of different kinds of pentesters, with different knowledge and focus areas. It’s easier to also buy security, these days.

Johan: If you feel you have the resources to actually fix things, you can also start a Responsible Disclosure program. You don’t even have to pay people, but people might look at your things anyway. Or, if they accidentally find something, they know how to contact you.

Responsible Disclosures can be fairly useful, because people can show it off on their resumé to help their career or online profiles, so they get invited to [private] bug bounty programs. There are a lot of those as not every [organization] wants to be public with their bug bounty program. 

It’s a win, win. You get help with your security, and they get credit for it, of course.

Laura: Yeah, absolutely. I think there must be some people who just want to do this out of good will, as well.

Johan: There are people that are doing security for charity, for example Hackers for Charity. Where they actually just purely do it out of good will. I would expect some people maybe want to exercise their skills just to get a technical challenge.

We’ve talked a lot about the past and the current state of security, and the new trends that have been emerging. But, where do you see us going from here?

Johan: I think all these frameworks, or CMSs, or even programming languages will become even better at making people make good decisions, when it comes to security. So, security by default, or maybe even have it as Theo de Raadt, the creator of OpenBSD, says something like, “Optional security is irrelevant,” where you don’t have a choice. But, I think we’ll become better at that.

Of course, automation is a thing, definitely. Quite obvious, in this case, when it comes to Disposable mail since that is what we do. But I really believe in that. As I mentioned, it’s harder and harder to get into the field of security, and there are fewer and fewer [individuals] that are doing this original [security] research. So we need to distribute that knowledge.

The futuristic way of security with automation and hacker collaboration:

Johan: Not everyone can learn to hack that well, and those insights shouldn’t be only for those few that can, or the few that can afford to hire these people. If you look at Google’s bug bounty program, or Facebook, or some others, they have an enormous budget. Obviously, that won’t go for everyone.

It’s not just the organizations themselves that would suffer from this, it’s all the users of the smaller websites, and organizations. What we need to do is find ways to distribute that knowledge, to spread that knowledge so we can get a more secure Internet experience.

That’s partly what we do. We try to take this knowledge from the few [Disposable mail Crowdsouce], and automate it so it can reach much more people. But knowledge would also go into those open source tools, or CMSs, or similar. I think that’s a futuristic way to look at security. At least, that’s what I believe, and hope for as well, so we don’t get this too-centralized where there’s a few services that you feel like you can’t actually trust because those are the only ones that can afford this kind of thing. It’s not just super big enterprises and nation states, it’s [security] actually more for everyone.

Ultimately, we need to protect the end user:

Laura: Absolutely. Even though companies need to be the ones enforcing security, a lack of security will always affect the end users in one way or another. Either their data is compromised, or their devices are compromised. The target for malicious actors is either a group of people, opportunistically everyone, or a really specific target, like one person.

Johan: That’s a lot of the point. If your company gets hacked, of course you as a company will suffer, it will damage your brand, and might have a lot of financial costs and things, but it also affects everyone that’s using your service. Or, if they have their personal data on that service, maybe other things that are even more sensitive ,… like Bitcoin wallets, that could have a huge cost for people.

Something more subtle would be like your email being leaked so now you get a lot of spam. That’s annoying, but it could lead to a lot of different things, depending on how you use it, and what kind of company it is. The point is, it’s not just the organizations that suffer, it’s all the users of it. We need to help everyone be more safe, or secure.

Full video episode on Wistia or find it on the Disposable mail Youtube channel:

Did you like the highlights of this episode? Check out the full episode of Undetected podcast and following episodes in the web player. It’s also available on Spotify, Apple Podcasts, Google Podcasts or another preferred podcast platform.


Keeping up with the fast-pace of web security is a challenge if you are only relying on standard CVE libraries and annual security checks. Disposable mail works with some of the best ethical hackers in the world to deliver security research and modules from the forefront of security, so you can stay on top of emerging threats. Interested in giving Disposable mail a go? Start your 14-day free trial today.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Gehaxelt – How WordPress Plugins Leak Sensitive Information Without You Noticing – 10 minute mail

Sebastian Neef (@gehaxelt) is a IT security freelancer and a top contributor from the Disposable mail Crowdsource community. In this guest blog, he looks at ways WordPress plugins leak sensitive data in the wild:

Guest blog post from Crowdsource hacker gehaxelt

The OWASP Top 10 puts Sensitive Data Exposure on the 3rd place of the most common web security issues. In this blog post we will have a look at sensitive data exposure that you might not be aware of. 

WordPress is probably one of the most used Content Management Systems out there. The vast amount of available WordPress plugins certainly plays a huge role, as it allows your WordPress blog to become a full-fledged online shop (i.e link: woocommerce). But relying on 3rd-party plugins to customize your blog or shop comes with certain security risks. There are no restrictions on who can publish a plugin on wordpress.org, so the code quality and therefore security can vary a lot. 

I have analyzed how the most popular WordPress plugins leak information with remediation tips so you can continue using WordPress in a more secure way. 

This research was part of my attempt to get some more valid submissions to the Disposable mail Crowdsource platform, so my focus was only on the top-ranking WordPress plugins. To qualify as a valid submission for Disposable mail Crowdsource, the vulnerable plugin needs to have at least 300,000 active installations and the issue needs to be exploitable remotely without any form of authentication. At least for the information disclosure the criteria was met for the following plugins: 

* A module for this plugin was not implemented due to an increased request complexity.

Taking all installation counts from the above list together and assuming that one installation equals one website, we end up with about 19 million websites that are potentially affected by an information leak issue.  

Let’s first have a look on what kind of information is leaked by those plugins. I think there are three categories of leaked data, which also seem to match with certain CWE (Common Weakness Enumeration Database) categories:

    • Credentials (CWE-200: Information Exposure)
    • Personal Identifiable Information (PII) (CWE-359: Exposure of Private Information (‘Privacy Violation’))
    • System Information (CWE-215: Information Exposure Through Debug Information)


From the attacker’s perspective, gaining access to credentials is the jackpot. It might allow them to obtain usernames, passwords or API keys that could be used to escalate their privileges. A WordPress administrator account is allowed to edit themes or plugins, thus gaining remote code execution is trivial. Leaked API keys are no better, because they might allow the attackers to abuse them, gain unauthorized access or just create huge financial damage.

Here’s a list of things that fall into this category and that I’ve seen leaked:

    • Passwords to protected posts
    • Backup files or zips
    • SMTP credentials

Personal Identifiable Information (PII)

The next level in the hierarchy is, in my opinion at least, personal identifiable information. Especially in 2020 with the new digital information processing laws and GDPR, it might become a company’s nightmare if customers’ PII become public due to hefty fines. For that reason, I was even more surprised to find several plugins to leak the following customers’ or users’ data:

    • Names
    • Email addresses
    • Usernames

System Information

The third category comes down to the remainder of information about the system running WordPress or its configuration. Most of the following types might not have direct, critical security implications, but could still give the attacker useful information for more sophisticated exploitation chains. Most of the WordPress plugins were leaking the following information:

    • Internal host names 
    • Database tables, SQL queries
    • Security logs
    • Full path disclosures
    • File names
    • Software versions (OS, PHP, MySQL, WordPress)
    • PHP Configuration (safe_mode, memory limits, execution limits, etc)

So far we have discussed what plugins leak information and what kind of information is leaked, but we haven’t looked at how this information is potentially exposed to the attackers. 

At the core, the issue lies within WordPress’ file permission scheme which mentions that the wp-content/ folder should be writable, because some plugins might need write permissions there. Depending on how secure you or your WordPress administrator is, the whole wp-content/ might have full rwx permissions, and therefore most plugins choose to create directories and files there. 

This is not a problem by itself, but becomes one as soon as some plugins begin to create log files with the above discussed information that the web administrator does not know about. Plugin developers are not guaranteed a writable “data” folder outside the document root, where they could securely store such log files containing sensitive information in a non-volatile way. PHP’s sys_get_temp_dir could be an option, because it is system agnostic (not everyone runs Linux), but it might not offer persistence. The latter is pretty important for log files. Therefore, most plugin developers opt for a folder that they can assume to be writable on most WordPress installations as this stackoverflow thread suggests:

    • wp-content/uploads/
    • wp-content/*

The former works in most cases, because files uploaded through WordPress’ media library end up there, so it is writable to not break core functionality. The latter includes all subfolders, such as wp-content/plugins/ or wp-content/themes, if the administrator wants to easily install new plugins or edit themes.  

If you are a security-minded person and you are running a WordPress instance, now is the time to ask yourself if you have reviewed the source code of all active plugins, or did you simply install a plugin, because someone needed it to change the website’s functionality? You should review your plugins, but first continue reading to know what you should look for.

I have noticed two different patterns that developers use to create log files, and only one of them has basic security principals in mind. However, both approaches become ineffective security-wise once the administrator forgets to properly configure the web server. Therefore, we cannot just put all blame onto the WordPress plugin developers for leaks, but we need to reinforce basic security principles at any time.  

Static file paths

Developers are not naturally security experts, and often they focus on building solutions that work. There is nothing easier than using WordPress’ wp_upload_dir() or WP_CONTENT_DIR to obtain the path a writable folder and appending a plugin specific suffix. 

Here is a list of example paths:


Let’s recall that the wp-content/ folder lives in the DocumentRoot is accessible from the internet, thus all the files within it are usually accessible, too. This makes it trivial for an attacker to access those log files and their content by navigating to the well-known paths.

Random file names

A good portion of the plugins implemented their logging functionality with more security in mind. By adding a random portion to the file name, it cannot be requested directly without knowing the random part.

Depending on the implementation, the portion’s randomness varied greatly:

  • an incremented 6-digit number (not really random)
  • a randomly generated string
  • a cryptographic hash (MD5 or SHA)

To a developer, this approach might look pretty robust and secure, but it disregards the fact administrators also play a role. Given that WordPress is an entry-level CMS, it might be set up and operated by novice administrators, who just followed a tutorial “to make things work”.

The file name randomization is instantly defeated if the administrator (accidentally) forgets to turn off “directory listing” on their web server. In such a case, an attacker just needs to browse to the respective folders to get a list of the random file names. 

index of /wp-content/uploads/wc-logs

While working on this topic, I have found several examples of such misconfigured web servers on the internet. It is not just a hypothetical scenario. 

If you have made it this far, you might be asking yourself how I discovered all those log file disclosures. I will happily answer this question in this section, so that you can review your own plugins.  There were basically three approaches to this topic: 

    • Find existing files
    • Review the plugins’ source code
    • Use a search engine

While the first method did not show anything interesting in particular, the second one was the most fruitful, but also the most time-intensive. There were over 115 plugins to review, so naturally I could not invest the time to do a thorough in-depth source code review, but rather took some shortcuts and educated guesses. Last but not least, I used search engines to discover files that I might not have seen with the two methods before. 

Let’s have a look at them in detail. 

Find-ing existing files

find is a small linux command line tool to quickly find files or directories in a file system hierarchy. After installing some plugins, I ran it on my test WordPress instances like this:

$> cd path-to-wordpress/wp-content/
$> find . -type f -name ‘*log*’ -ls 
$> find . -type f -name ‘*txt*’ -ls
987828	4 -rw-r--r--   1 gehaxelt gehaxelt  	229 Feb  9  2018 ./sc_cache.txt 

This showed me a few files containing log or txt, thus matching either of the two regular expressions. It is by far the most efficient method to check if such files exist on your web server. If you are administering any WordPress instances, take a note and check your web servers  after you have finished reading.

Source Code Review

Most of the work done was source code review using a few lines of bash, grep and less. 

As the first step, I downloaded all plugins with more than 300k installation from the wordpress.org website and extracted them into separate folders. A few lines of python helped with that task. 

The next step was to look for and identify paths where log entries are written to. PHP offers a few methods such as file_put_contents or fopen to create files. By having access to the source code, using the command line text searching tool “grep” was a suitable choice. Keywords such as “file_put_contents”, “file_get_contents”, “fopen”, “log”, gave a good idea where to look for. 

From there, it became going bottom-up through the code and deducing where the file would be written and if it is randomized or not. 

Google Dorks

(Ab-)using search engines and their specific search keywords for security purposes is often referred to as “dorking”. No sophisticated hacking tools are required for such an attack, just a web browser, a search engine such as google and a query like inurl:"/wp-content/uploads/wp-google-maps/error_log.txt" would be enough to find a whole lot of affected websites.

I took the route of searching for a plugin’s directory name while adding keywords like log or txt etc. It gave mediocre results, but that was better than nothing and also helped to verify the findings from the previous step. 

Overall the results using this method are limited to web sites that usually have DirectoryListing enabled and make their contents indexable by certain search engines. 

We all know that breaking things is much easier than fixing it. I tried to come up with ideas for how to prevent such information leaks to make the ecosystem more secure.  

Rule #1: Use randomized file names

Static file paths make it insignificant for an attacker to check the existence of a file and download it. Using randomized file names might take a bit more time for a developer to implement, but boosts the security immensely. Especially since the majority of web servers should have directory listing disabled, so that an attacker cannot guess the correct file name. 

Rule #2: Prevent directory listing

Even the scenario of a directory-listing enabled web server can be mitigated by the plugin developer: For every folder that is created and where plugin-specific log files are written, an empty index.php file should be created. On literally every web server the index.php file is configured as the DirectoryIndex, meaning instead of showing all contents of a directory, this file will be executed. As an empty file has no content, the attacker won’t see a list of file names, but an empty page. 

Rule #3: Workaround

If Rule #1 and Rule #2 are not followed by a plugin, then one could try to move the created folder outside the “DocumentRoot” (i.e. using a symlink). Alternatively, explicit rules must be created to prevent access to static or randomized log files. Depending on the used web server, simple “.htaccess” files could be used. 

Rule #4: WordPress hardening

The WordPress developers have a lengthy article on WordPress security and hardening. At the time of writing it contained a neat statement which fits this topic perfectly: 

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. 

It is always a good idea to go over this article and check if oneself has considered and implemented the given hardening tips.

To round this section up, I firmly believe that most plugins should be able to implement and follow Rule #1 and Rule #2. The other two rules, Rule #3 and #4, lean more towards the side of the system administrators, but we cannot take them out of the equation. If a WordPress instance is provided for you, don’t forget to ask the responsible administrator to go over the issues mentioned in this article.  

All of the initially listed WordPress plugins and their potentially leaked log files have been implemented into Disposable mail’s automated security and asset monitoring since September – November 2019. The security modules will give you insight into which log files on your web server are discoverable by an attacker. That means, the modules can:

    • easily identify the “static file path” log files 
    • detect the “randomized file path” log files, too, as long as the randomization can be circumvented with the method discussed earlier

My research doesn’t stop here. I am continuously pursuing this topic in order to bring more log file disclosures to users to secure more websites through the Disposable mail and the Crowdsource platform.


Written by:
Sebastian Neef
IT Security Freelancer and Disposable mail Crowdsource hacker

Sebastian Neef (@gehaxelt) is a security researcher at heart and has been interested in IT security since the age of 15. He became an IT security freelancer and consultant during his A-Levels back in 2012 when bug bounty and responsible disclosure programs were just starting out. Sebastian enjoys sharing his knowledge on conferences or his blog 0day.work, breaking things, playing CTFs with ENOFLAG and helping companies to improve their security. 

How can Disposable mail help?
Disposable mail works with highly skilled ethical hackers like Gehaxelt to crowdsource the most up-to-date security research. Check for the latest WordPress vulnerabilities and 1500+ other known vulnerabilities with a start of a Disposable mail scan. Begin your 14-day free trial today.

Additional reading:
Improving WordPress plugin security from both attack and defense sides

How to Improve Your WordPress Security: Plugins and Themes

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Web security trends 2020 from 3 security leaders – 10 minute mail

In part 1 of web security trends 2020, we discussed the rise of Crowdsourced Security and the ever-changing attack surface. This time we turned to 3 security leaders to get their perspective on trends to come in 2020:

Anne-Marie Eklund Löwinder

CISO at the Swedish Internet Foundation, Internet Hall of Fame (2013) and holder of one of The Keys to the Internet:

Photo of Anne-Marie Eklund Löwinder (source: internetstiftelsen)

Photo of Anne-Marie Eklund Löwinder (source: internetstiftelsen)

What security issues/trends are you anticipating for 2020?
We are all targets. I believe that the world of digitalization continues to grow in complexity. As a result of that, it becomes even more difficult to protect the technical environment appropriately in our homes and workplaces.

With more and more systems and software, plugins and apps, we will continue to be challenged with keeping everything updated. Attackers will probably outpace incomplete and hurried patches. With more devices brought to our homes, most of them with network access with or without our knowledge, the exposition will let cybercriminals to home in on IoT devices for espionage and extortion. The digitalization leads to critical infrastructures being more exposed and they will most certainly be plagued by more attacks and production downtimes (I’ve just finished reading Sandworm by Andy Greenberg).

The increasing use of cloud services continues to change the security map. When more and more companies are handing over their information to someone else’s IT environment, aka cloud service providers, vulnerabilities in their environment, such as container components, will be top security concerns for DevOps teams.

Some novelties will introduce new attack surfaces for misconfiguration and vulnerable codes. Not monitoring enough will result in bigger damages than necessary. User misconfigurations and insecure third-party involvement will also compound risks in cloud platforms.

Threat intelligence will need to be augmented with security analytics expertise for protection across security layers. Which means companies must put more resources on security. But will they? Are the executive leaders of the companies willing to act upon the increasing risks? To what extent?

Are there any trends to do with security automation or ethical hackers? 
I am not aware of any specific trends that do with security automation or ethical hackers, but the value in skilled ethical hacking is critical for identifying vulnerability in cybersecurity solutions before a real bad actor comes along. NSA recently handed over a serious vulnerability in Windows 10 to Microsoft, which to me shows a change in behaviour. Maybe they understand the problem with keeping them secret for future use when the collateral damage threatens to be global.

What are your current challenges and how do you plan to tackle these this year?
My current challenges are to keep the staff (at the Swedish Internet Foundation) happy by offering new and modern solutions, and keep them informed about the risks and of what’s going on at the same time.

What event do you look forward to in 2020?
Internetdagarna! As always.

Tanya Janca

Application security specialist, Ethical hacker, Pentester, Women in Security co-founder, frequent speaker:

Photo of Tanya Janca

Photo of Tanya Janca, application security specialist, pentester and frequent speaker

What security issues/trends are you anticipating for 2020?
I anticipate more breaches and news stories of ‘cyber tragedy’, but also more companies investing in their employees via training and enablement in the workplace to create processes for faster and more effective security.

I also think we will see a lot more cultures moving towards DevOps and automation of security testing, defences and detection. I believe the Information Security field will try to move towards using more Artificial Intelligence/Machine Learning to provide better security experiences, for better or worse. I also foresee many companies abusing new technologies to violate user’s privacy, which is a trend I find both unethical and worrisome.

Read: Tanya’s blog series on DevOps and security: Pushing Left, Like a Boss.

Are there any trends to do with security automation or ethical hackers?
More and more development shops are realizing that if they don’t move to the DevOps model/culture they will no longer have a competitive advantage. I am currently seeing many security teams that are getting on board with this, adding automation, security sprints and adding security tooling to CI/CD pipelines, and other forms of “DevSecOps” (application security activities that are adapted to DevOps environments). I’m also seeing quite a few mature AppSec companies creating stripped-down versions of their tools to be used in pipelines, with varying results, and newer companies that have CI/CD in mind when creating brand new products.

I’m very, very excited to see innovation in this area in 2020. Application Security is a young field, and I suspect there will be very new types of tools coming out to solve this problem in new ways, and I can’t wait to see it.

What are your current challenges and how do you plan to tackle these this year?

This year I have three career goals:

  • to help guide and support a few new AppSec startups in hopes to help them launch new and innovative products
  • to create DevSecOps and AppSec training that is affordable, accessible and fun
  • to have a better work/life balance than I have had in previous years.

I will also continue to coach companies launching and improving their AppSec, DevSecOps and Azure security programs. Wish me luck!

What ways will you/your team measure success this year?
I keep personal and professional KPIs that I won’t share here, but I can say that I believe setting goals and measuring yourself (regularly) against them is a fantastic way to ensure you reach your version of success.

I also believe in setting and enforcing personal and professional boundaries (for example, I do not take meetings before 9:00 am because sleep is very important to me). Setting a list of yearly/quarterly/monthly goals, as well as a set of boundaries, is an activity that I feel would serve any person well in their career.

What event do you look forward to in 2020?
I always look forward to every WoSEC (Women of Security) meetup, especially the “WoSEC Crashes RSAC” meetup during RSAC this year! I’m also looking forward to several different locations of B-Sides, and I especially love the AppSec conferences from OWASP.

Laura Kankaala

Security Researcher and Undetected podcast host at Disposable mail, ethical hacker, Disobey board member and frequent speaker:

Photo of Laura Kankaala

Photo of Laura Kankaala, security researcher, Disobey board member

What security issues are you anticipating for 2020? 
Security of cloud environments and understanding exposed attack surface is going to be crucial for companies to secure sensitive data. Having sensitive data storage or internal servers accessible over the Internet and indexed directly in services such as Shodan is an unnecessary risk that companies are taking with their infrastructure. As of writing this, there are more than 73,000 MongoDBs available indexed in Shodan. Most of these are likely hosted in some Software-as-a-Service (SaaS) platform.

On the positive side, I think companies are becoming more vigilant about security. It is kind of hard to ignore security because data breaches and security incidents are constantly in the mainstream media. I encourage companies of all sizes to take a critical look at their security practices and at least include a responsible disclosure policy on their public website.

Are there any trends to do with security automation or ethical hackers? 
I’m sure the usage of crowdsourced security will increase, it seems like the number of bug bounty programs, both public and private, outnumber the active researchers. For Crowdsourced security to be successful, we [security professionals] need to get better at sharing knowledge and offer help to get people started in security research.

However, bug bounties are just one facet of ethical hacking, as they typically just scratch the surface of the overall security of the company. For example, fixing an XSS bug found by a bug bounty researcher won’t fix the root cause of why XSS vulnerabilities exist. Preventative measures like security tools and educational content should reach the developers without increasing their workload tremendously.

When it comes to automating security, I think it is important to automate tedious tasks to pave way for tasks that require more time and attention. Automation also works to provide more consistency in security testing results in different phases of software development. In order for companies to grow bigger and faster in a secure manner, it makes a lot of sense to employ automation in the appropriate places.

What are your current challenges and how do you plan to tackle these this year?
This challenge will probably span over multiple years, but I want to make security automation the norm.

What we are doing at detectify is in addition to in-house security researchers we work closely with Crowdsource ethical hackers all around the world to be able to tap into the knowledge of novel vulnerabilities to complement our security automation tool. I don’t think this is necessarily a challenge, but more like a great opportunity for our customers to get insight into the security posture of their web applications and get knowledge of zero-day vulnerabilities as soon as possible.

What ways will you/your team measure success this year?
For me, success doesn’t happen in a void. Things are either done or they are not done. Getting things done can surely be a success, but will it truly matter unless it has a positive effect on someone else’s life?

My team and I have set numeric and performance-based goals that are a general path to follow. However, to be successful, the teams need to meet more than numbers and performance metrics. We need to collaborate and provide something meaningful to our community and peers.

What event do you look forward to in 2020?

I have a personal stake in this, but I am looking forward to Disobey that we are organizing in Helsinki, Finland. I am on the board of members for this conference so I hope that everything runs smoothly. We have a very active infosec community in Finland, but it’s exciting to see people from all over the world attending our event, either as a speaker or as an attendee.

How can Disposable mail help with your security plans for 2020?

Keeping up with the fast-pace of web security is a challenge if you are only relying on standard CVE libraries and annual security checks. Disposable mail works with some of the best ethical hackers in the world to deliver security research and modules from the forefront of security, so you can stay on top of emerging threats. Interested in giving Disposable mail a go? Start your 14-day free trial today.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

M. Loewinger, Smartbear: “Each Product DevOps Lead manages Disposable mail and all its findings” – 10 minute mail

Disposable mail user story: Smartbear offers automated software testing solutions that help development and testing teams ensure quality throughout the software development lifecycle. Martin Loewinger, Director of SaaS Operators at Smartbear, and his team use Disposable mail to ensure security is a part of each product CI/CD pipeline, so that they can help their end users with test automation and monitoring.

What is your role at Smartbear?
I am the Director of SaaS Operations. I have the pleasure of leading the DevOps teams who support, maintain, and help build and design our SaaS platforms. Our DevOps teams are the leads when it comes to the platform’s infrastructure, configuration, security and deployments. We basically handle everything but creating the software. This past year I was fortunate enough to be given a development team to lead as well. I manage and lead the development efforts for our AlertSite product.

How does Smartbear work with security and development?
At SmartBear, some of our products service thousands of customers and span the globe. Disposable mail helps us monitor the security of our SaaS products, and currently we scan over 30 unique URLs or products. Some of the products are externally exposed and some are private. We have integrated Disposable mail into our CI/CD pipeline, which means that prior to releasing code to production, we have run and verified a Disposable mail scan in our staging environment. Any new findings are triaged by a DevOps and Development lead. If needed, production releases are postponed until the security finding is resolved or mitigated.

“We have created security champions on each of our scrum and development teams.” – Martin on getting devs to care about security


One for the CISOs and managers out there… 
What are some of the goals set for your security team and how do you measure success?
Although not an official goal for the year, I would say that my personal goal for 2020 is zero breaches/exploits of my systems. I would say this can be simple enough to measure… have none! 

No but seriously, one of our goals is to have zero critical vulnerabilities reported in our applications due to human error. This means that any findings we have should not be a result of a misconfiguration.

What are some of the challenges your security team faces?
We have an extensive portfolio of SaaS products and infrastructure, and of course their security is extremely critical. Our challenges in monitoring and keeping 100% compliance on patches can become daunting. This is why we have Disposable mail and other several tools and systems to help us.

Finding a balance between security and business development is also a challenge we would like to solve. Security can become a blocker to product innovation, meaning a feature may need to wait or even be put off in order to have development concentrate on a security finding, and I am sure many other companies face this as well.

How does Disposable mail fit into this? 
Disposable mail is critical in helping us ensure the next release does not expose us to a major security issue. Our daily and weekly scans help us with monitoring the applications and products.

Our teams manage operations and security for many of our products and as a result, we work with many different stakeholders. Each product has a DevOps lead who manages Disposable mail and all its findings, who then works with a product’s development lead and escalates any findings and issues which need to be resolved.

Besides using Disposable mail, how else do you work with ethical hackers?
SmartBear Software currently has a private Vulnerability Disclosure Program with a leading security vendor.

Which is your favourite function in Disposable mail?
Our team likes the JIRA integration within Disposable mail. Since we are working with multiple product teams at once, we can simply and quickly escalate findings to the appropriate developer or teams.

What are some of the common security mistakes you see?
Misconfiguration is the most common security mistake we see.

“…one of our goals is to have zero critical vulnerabilities reported in our applications due to human error.” – Martin on security goals for 2020


What are some common attacks you see in your day-to-day when defending Smartbear?
We monitor our systems 24/7 for attacks. We mostly see the usual scans looking for default username and passwords for many of our public systems. The usual port scans, and possibly unpatched vulnerabilities.

How do you get developers to care about security?
We have created security champions on each of our scrum and development teams. It is the champions responsibility to push security amongst their team. Ultimately we need and want to build bug bounty-grade applications, which means our ideal goal is to make these programs public and open to everyone.

How do you stay up-to-date with security news/trends?
You name it, we do it. From being on Slack groups, attending conferences, email lists, GitHub Alerts and news outlets. Our security vendors like Disposable mail are also great in distributing security news and trends.

Get started with automating security into your DevOps or CI/CD practices today using Disposable mail. We collaborate with 200+ ethical hackers to offer checks for 1500+ common web vulnerabilities. Sign up for your free 14-day trial.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.