I've found a little vulnerability in a web application running on Node.js server.

It works by sending some crafted payload to the application server, which makes the application server code to throw an error and due to lack of error handling - It crashes (until someone runs it again).

I'm not sure what is the appropriate name for this kind of attack. I assume it's a DOS (Denial Of Service) attack because it makes the server Deny Serving its clients. On the other hand, Until now, I've only heard of DOS attacks which works by flooding the server in some way (which isn't the case here).

So, is it correct to consider it as a DOS attack? If the answer is no, so how should it be called?

  • 5
    If an application is well-written then it won't have any crash-type DOS bugs and an attacker will have to resort to a full DDOS (which will always work if the attacker has a bigger firehose than the target). However if the target app has an easy-to-trigger crash, then I'm sure any attacker would rather send the single crafted packet and save themselves the $$ of running a DDOS network. Jan 29, 2019 at 23:06
  • 33
    As long as it prevents users from using the service it is a DOS. I have worked on a website that was DOS attacked by Google and Bing simply because Drupal cannot handle the load (I wanted to say could not but I believe it still can't).
    – slebetman
    Jan 30, 2019 at 2:25
  • This would be a DoS attack, specifically I have seen such attacks called “poison pill” attacks before... but I am unable to find a reference for this right now
    – Josh
    Jan 30, 2019 at 4:11
  • 11
    I would change your title to a “triggered” software crash. Random crashing isn’t really DoS, but the fact that you can cause it on command is the key part.
    – zero298
    Jan 30, 2019 at 6:30
  • 3
    I think a little bit more detail about this point is important: It crashes (until someone runs it again). What happens to future requests, exactly? If the server crashes for you, but continues operating normally for all other users, then I would say you have more of a bug then a DOS attack, because the service is still available to other people. Technically you have DOS'ed yourself, so there is a bug for them to fix, but if the only impacted user is yourself then you don't have much of an attack (typically). Jan 30, 2019 at 13:50

7 Answers 7


Yes. Any attack which has as a goal to deny the normal usage of a service by legitimate users is by definition a DoS (Denial of Service).


DDoS (Distributed DoS) is characterised by floods creating a DoS (in all available definitions). A single node causing a flood successfully is kind of rare.

But DoS can be caused by a broad range of triggers.

CVSS even has an example of a software crash classified as DoS for you:

Due to a flaw in the handler function for RPC commands, it is possible to manipulate data pointers within the Virtual Machine Executable (VMX) process. This vulnerability may allow a user in a Guest Virtual Machine to crash the VMX process resulting in a Denial of Service (DoS) on the host or potentially execute code on the host. [empasis mine]

And from Wiki:

Denial-of-service attacks are characterized by an explicit attempt by attackers to prevent legitimate use of a service. There are two general forms of DoS attacks: those that crash services and those that flood services. The most serious attacks are distributed.

So, yes, a simple crash is a DoS.

  • 17
    DDoS is characterised by being a distributed attack, but not necessarily by being a flood. When you send a single crash-payload whenever the server comes back online and always use a different botnet zombie to do it in order to avoid IP blacklisting, that would also be a form of a DDoS attack.
    – Philipp
    Jan 30, 2019 at 12:11
  • 2
    @Philipp I'm not sure about that. That seems like a serial DoS. Every reference I can find to describe DDoS has been to characterise the event as a flood from multiple sources creating a DoS, not a DoS from multiple sources. Can you provide anything to support your example?
    – schroeder
    Jan 30, 2019 at 12:18
  • 5
    @schroeder I suspect that's because many (or, at least, the easiest to achieve) DoS attacks involve flooding, and flooding from multiple sources is more likely to overwhelm a target. Thus most DDoS attacks do involve multiple-source flooding, but – I would argue – "flooding" that isn't the definer of DDoS attacks, whereas "multiple-source" is. A carefully crafted attack, such as the OP asks about, coming from multiple sources (to hamper IP blacklisting) would legitimately be a DDoS.
    – TripeHound
    Jan 30, 2019 at 13:58
  • 3
    Just speaking from a logical perspective, it makes sense to me that the defining charactaristic of a DDOS is that the distributed of the attack prevents the defender from mitigating the attack. The defender really needs to be specified for that to make sense. I would not consider sending single crash-payloads to a server application whenever it comes online a DDoS against the server application, but it might be seen as a DDoS from the perspective of a lower tier defender (perhaps a firewall) that may not be able to block this attack because it keeps coming from different IPs each time.
    – Cort Ammon
    Jan 30, 2019 at 16:45
  • 5
    Yes, everyone, I fully agree that DDoS could possibly, logically mean a distributed attack of any kind. But, I can find no reference to this meaning being used in practice and even the proposed example seems to me like a string of attacks, and not a single attack (although distributed). If anyone can help with a concrete example, I'd be grateful. Actually go out and count the horse's teeth.
    – schroeder
    Jan 30, 2019 at 16:53

Quite often security is looked at as providing three properties:

  • Availability
  • Integrity
  • Confidentiality

In your case, you've found something that allows a user to affect the availability of the service. Depending upon what the service provides, that might be annoying or it might be catastrophic.

Quite often failed services will be automatically restarted. These can mitigate occasional crashes, but restarting a service is usually far more expensive than the usual cost to handle a connection. In this case, executing your 'crash the server' request five or six times a second might not be much bandwidth but is still probably pretty rough on the average server.

  • 2
    Also, good service managers don't restart services without limit. Chances are, something that makes the service crash might also be exploitable in other ways, and blindly restarting the service gives the attacker another shot. Jan 31, 2019 at 10:28

I wanted to add one more important detail not explicitly stated in the other answers. You said this:

It works by sending the server some crafted payload, which makes the server code throw an error, and due to lack of error handling - It crashes (until someone runs it again).

(emphasis mine). That caveat is important because the way such services respond to a crash can vary wildly between technology sets.

Not a DoS

For instance in PHP or most cgi implementations, a single crashed request has absolutely no impact on other requests. The server fails to send a proper response for the crashed request, but other requests coming in from legitimate users continue to be handled properly by the server. In this case the crash only affects yourself - not others - and so it would be hard to qualify that as a DoS attack. Sure, there is a bug, and you are denying yourself service, but if the server continues to operate normally for everyone else then there isn't really any denial of service going on.


If, however, your payload causes the actual service to go down and no more requests can be received by the server until some action is taken to restore services (whether by an admin or automatic restoration after a short period of time) then you definitely have a denial of service because the crash you caused stopped the service from responding to legitimate users (as discussed in other answers).

Under some circumstances the "Not a DoS" attack that doesn't take down the server could possibly be promoted to an actual DoS attack if you can "trick" a legitimate user to visit a URL with your malicious payload. Most of the time though such attacks don't have much practical impact since the service will continue to operate normally when they later use the service normally. However there could be rare circumstances when the payload is persisted to the session and therefore permanently locks out the user (I've seen people accidentally trigger such circumstances in real life before).

From your description, it's hard to tell which of these categories your particular payload falls into, but there is an important distinction to be made.

  • DoS can also apply if you trick a valid user into running the payload. The DoS is localised, but it still counts as a DoS.
    – schroeder
    Jan 30, 2019 at 14:02
  • @schroeder Yes, true, although it is hard to make such attacks have substantial impact, which is why I left it out (I'll add a comment about it though). Typically that kind of attack can get the affected user to have a failed page load, but if they return to the page in normal usage everything works like normal. It is possible to have a case where the bad payload gets persisted to the session in some way, which can end up effectively DoS'ing a single user - that can be a very effecitve DoS attack. Jan 30, 2019 at 14:19
  • 2
    In node you have a small number of single threaded servers. so a server crash affects all active users (of course automatic restart is a good idea but continually crashing the process will severely hurt the service). However what should be more of a concern is what kind of crash that is... could be exploitable (logical processing aborts would not terminate the node binary).
    – eckes
    Jan 31, 2019 at 1:01
  • 1
    PHP FastCGI or FPM uses one PHP worker process per request and a fatal error would only kill your worker process, and the FastCGI daemon would span another. But what happens if your error is so bad that it kills apache (or whatever webserver you're using) -- then it's a DOS attack. I've seen this before (where the bug was in an Apache module) and the result was nothing listening on port 80 anymore and a total loss of service
    – Josh
    Jan 31, 2019 at 4:37
  • Thanks @eckes, I'm not a node guy so I don't know much about how it handles unhandled exceptions. Jan 31, 2019 at 11:45

Your attack is basically the definition of DOS, it literally denies service and you are using the term correctly.

Consuming bandwidth is a naive approach that does not require the sever to have a specific vulnerability, but is certainly not the only one.

Here is a real CVE about Apache describing a similar DOS attack (crashes with segfault) using that terminology:


Even more complicated attacks are sometimes trivially DOS attacks and are given that label as well. A stack smashing remote code exec bug without a shellkit still smashes the stack with incorrect values causing a segfault.


Yes this could be called a DOS vulnerability. I have heard this called an "Application DOS Attack".

Another example: a site that runs a virus scanner over uploaded files, where someone uploads a zip file of 100,000 zip files containing 100,000 2gb files of zero bits. A super small zip file that uses all of the available memory to open and scan.

If you are denying a legit user from utilizing a resource [CPU, Ram, Disk, Network bandwidth (password resets?] then you could call it a DOS attack.

If however the attack just corrupts the application's state (say lets an unauthorized user set the app into read-only mode) then I might be inclined to just call that an application (or security) vulnerability.


Does it make sense to consider a server software crash, as a DOS attack?

Any actor will act in at least two dimensions with regard to any activity: ability and permission.

Ability has 2 possibilities: able and unable.

Permission also has 2 possibilities: allowed or denied.

Therefore, a nice actor will perform an action only if able and allowed.

From my point of view, software crash=unable and DOS=denied. Since the two are "values" on different dimensions, they cannot be considered similar, even if the effects to the end-user may be similar. However, the effects seen by the network admin may be totally different - the solutions for them are usually different.

Also, a DOS attack may lead to a software crash, but they are still not similar - they are only related - cause and effect.

Example: any software may crash for uncountable number of reasons even in the absence of any attack.

Note: software crash usually means that the process is stopped by the OS because of a faulty operation. DOS are possible usually because the software just misbehaves, but does not crash.

  • DoS is not a permissions issue. The basic definitions of the terms contradict your premise.
    – schroeder
    Jan 30, 2019 at 12:57
  • Even so, the terms are not similar. Therefore I assume that my answer is correct, even if the "metaphor" is not perfect. So the downvote should not refer to the whole answer. Moreover, D in DOS is "Denial" (exactly as I wrote) - so again I do not really understand the downvote.
    – virolino
    Jan 30, 2019 at 13:17
  • 5
    You are factually, linguistically, and logically incorrect. You are trying to apply definitions of parts of terms out of context to devise a meaning and the result makes no sense. I could walk through the errors in logic, but the fact is that the term "DoS" is defined by the intentional loss of service to legitimate users, and a crash is one core example of this classification of attack.
    – schroeder
    Jan 30, 2019 at 13:21
  • If I use your terms, the malicious actor is able and allowed (that is, not denied, given your definitions) to send a crafted packet to stop the service. So your conclusion is faulty from the start. Your next point makes no sense whatsoever given the context you gave the terms you are using, so your argument is based on a change in definitions. The result is that your logic has no flow.
    – schroeder
    Jan 30, 2019 at 13:25
  • 1
    A software crash counts as a Denial of Service because it prevents otherwise legitimate users from using the service (i.e. denies them service), because the service can't be used when the process is not running. One might ask, how does a DDoS reduce legitimate users' privileges?
    – HAEM
    Jan 30, 2019 at 14:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .