Suricata

Typo:

I've observed this with Suricata versions 2.0.8-1ubuntu2 and 2.1~beta4-0ubuntu12 from the PPAs.

The rule I'm using

alert http any any -> any any (msg:"FILE store all"; filestore; noalert; sid:15; rev:1;)

Is the file fully stored indeed? (MD5sum matches for example?)
Can you please share a pcap (privately if you would like) that can reproduce the case.

Yes. The stored files are intact, with matching hashes, I've sent a couple example pcaps to your gmail account.

The report is correct (for 2.0.8 and 2.1beta4) - however this is fixed in the latest dev (2.1dev (rev 4a73802):

cat log/files-json.log 
{ "id": 1, "timestamp": "09\/20\/2015-16:48:27.256455", "pcap_pkt_num": 38, "ipver": 4, "srcip": "192.168.56.1", "dstip": "192.168.56.101", "protocol": 6, "sp": 80, "dp": 49158, "http_uri": "\/foo.exe", "http_host": "ecxample.com", "http_referer": "<unknown>", "http_user_agent": "Mozilla\/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident\/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)", "filename": "\/foo.exe", "magic": "PE32 executable (GUI) Intel 80386, for MS Windows", "state": "CLOSED", "md5": "d13eac51cd03eb893de24fc827b8cddb", "stored": true, "size": 24576 }

cat log/eve.json 
{"timestamp":"2015-09-20T16:48:27.256455+0200","flow_id":26503184,"pcap_cnt":38,"event_type":"fileinfo","src_ip":"192.168.56.1","src_port":80,"dest_ip":"192.168.56.101","dest_port":49158,"proto":"TCP","http":{"app_proto":"http","url":"\/foo.exe","hostname":"ecxample.com","http_user_agent":"Mozilla\/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident\/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)"},"fileinfo":{"filename":"\/foo.exe","magic":"PE32 executable (GUI) Intel 80386, for MS Windows","state":"CLOSED","md5":"d13eac51cd03eb893de24fc827b8cddb","stored":true,"file_id":1,"size":24576,"tx_id":0}}

Will the fix be applied to 2.0.x?

Commit is d837562441fae6f5b3a246f26b73654d687b71d3, will see if it can be backported.