`111.90.150.2044` is not a valid standard IPv4 address. The reason is straightforward: an IPv4 address contains four decimal components, each ranging from 0 to 255, while the final component here is `2044`.
That means the string, as written, does not identify a conventional routable IPv4 host. It also does not by itself identify a company, physical location, malware operation or threat actor. Claims that it is a special “hybrid IP” or automatically represents a cybersecurity threat go beyond what the technical standards establish.
Is 111.90.150.2044 a valid IP address?
No.
Split the string into its four dot-separated components:
- `111` — valid IPv4 range
- `90` — valid IPv4 range
- `150` — valid IPv4 range
- `2044` — invalid because it exceeds 255
RFC 3986 defines the familiar dotted-decimal IPv4 form as four decimal numbers, each limited to values from 0 through 255. The underlying IPv4 specification, RFC 791, describes an Internet address as 32 bits divided into four octets.
Because `2044` cannot fit within an IPv4 octet, the exact string fails the standard IPv4 format.
Calling it a “hybrid IP” does not solve that problem. That description has appeared on some websites discussing the keyword, but it is not the standards-based classification for this value. The more accurate description is a malformed IPv4-looking string.
Why does 2044 make the address invalid?
Each IPv4 octet is eight bits long. Eight bits can represent 256 possible values, from decimal 0 to 255.
A value such as:
`192.168.1.200`
can therefore be structurally valid.
A value such as:
`192.168.1.500`
cannot, because `500` falls outside the permitted range.
The same rule applies to `111.90.150.2044`. Its first three components fit the IPv4 grammar; the fourth does not.
This matters because software, security tools and lookup services should not treat every dotted string of numbers as a real IP endpoint simply because it resembles one.
What could 111.90.150.2044 actually mean?
Its original meaning is unknown.
A malformed value can arise from an ordinary typing error, a broken export, copy-and-paste corruption, incorrect parsing or data fields being combined improperly. Those are plausible explanations for malformed addresses in general, but none has been established as the origin of this particular string.
Two interpretations appear frequently online: that the intended address was `111.90.150.204`, or that `2044` was meant to be a port number. Neither has been confirmed.
Is it a typo for 111.90.150.204?
`111.90.150.204` is a syntactically valid IPv4 address, but it is not the same value as `111.90.150.2044`.
Removing the final digit creates a different address. There is no technical rule allowing that correction automatically, and there is no confirmed original record showing that `.204` was what the author intended.
As of September 25, 2026, IP intelligence data mapped the separate address `111.90.150.204` to AS45839. APNIC identifies AS45839 as SHINJIRU-MY-AS-AP, registered to Shinjiru Technology Sdn Bhd in Malaysia.
Those details apply to `111.90.150.204`, not to the malformed `.2044` string. They should not be transferred from one to the other.
Could 2044 be a port?
Port `2044` is a legitimate port number. IANA places it within the User Port range and lists the service name `rimsl` for TCP and UDP on port 2044.
That corrects another claim found in some articles describing 2044 as a “non-standard” port.
But the existence of port 2044 does not prove that this keyword contains a port. Normal host-and-port syntax uses a colon, for example:
| String | Meaning |
|---|---|
| `111.90.150.2044` | Invalid IPv4-looking string |
| `111.90.150.204` | Valid but different IPv4 address |
| `111.90.150.204:2044` | Syntactically valid IPv4-plus-port expression |
The third example is a valid form, but it is not a simple restoration of punctuation from the original keyword. Removing the colon from `111.90.150.204:2044` would produce `111.90.150.2042044`, not `111.90.150.2044`.
There is therefore no reliable basis for declaring `111.90.150.204:2044` the intended value.
IANA also cautions against treating a registered port number as proof that real traffic belongs to its registered service or is benign.
Is 111.90.150.2044 a cybersecurity threat?
The malformed string alone is not evidence of malware, hacking, phishing or command-and-control infrastructure.
Some pages discussing the keyword have attached cybersecurity narratives to it, including claims about malware signatures, disguised traffic and suspicious endpoints. No authoritative incident report or documented malware analysis in the supplied record establishes those claims for this exact value.
A malformed address can certainly appear inside malicious data, just as it can appear because of a typo or formatting fault. The surrounding activity determines the security significance.
If the string appears in a security alert, stronger indicators would include the actual source address, request activity, authentication failures, scanning patterns, attempted file access, protocol details and other correctly recorded telemetry.
The appearance of `2044` where an IPv4 octet should be is not enough to reach a threat verdict.
Why does an invalid IP-like string appear online?
Invalid strings can still be indexed like any other text.
By September 2026, several websites had published pages specifically discussing `111.90.150.2044`. Some correctly identified the invalid final octet, while others repeated unsupported ideas such as a special “hybrid IP,” malware functions or an automatic connection to the separate `.204` address.
The exact token was also observed on an unrelated property-management website inside a very large data-like block containing phone numbers, domains, names and numerous other malformed IP-style strings. Its presence there establishes only that the text appeared on the page. It does not establish that the website was compromised or that the number came from genuine network traffic.
Another cluster of pages published on April 9, 2026 used essentially the same collection of malformed identifiers in articles claiming to inspect “incoming call data logs.” The pages did not provide the underlying raw logs or documented provenance for those records.
That duplication helps explain how an unusual string can acquire a broad search footprint without proving that it ever represented a functioning network endpoint.
What should you do if it appears in a real log?
Do not “fix” the value before checking the original data.
Start with the untouched source record and determine how the application actually stored the event. Useful checks include:
- Confirm the exact timestamp and timezone.
- Identify separate source-IP, destination-IP and port fields.
- Check whether a colon, space or other separator was stripped during export.
- Compare the entry with correctly formatted records from the same system.
- Inspect nearby request, session or transaction identifiers.
- Review application, firewall, proxy or web-application-firewall records from the same event.
- Check parser, database and CSV-export rules if malformed values appear repeatedly.
- Preserve the original entry before making corrections or creating firewall rules.
Do not automatically substitute `111.90.150.204`, geolocate that different address, or block it simply because it resembles the malformed text. A correction should come from the original record or another reliable field, not from guesswork.
What current search results get wrong
Several recurring claims deserve a clear distinction.
“It is a hybrid IP address.”
The standard technical result is simpler: the string is not valid dotted-decimal IPv4 because `2044` exceeds 255.
“Port 2044 is non-standard or inherently suspicious.”
IANA registers port 2044 as `rimsl` for TCP and UDP. Registration does not establish what this particular string means or whether traffic on that port is trustworthy.
“111.90.150.204 is the real or base IP.”
It is a separate valid address. No confirmed source establishes that it was the intended original value.
“111.90.150.2044 identifies malware infrastructure.”
Malformed syntax does not demonstrate malicious activity. Security attribution requires actual incident or traffic evidence.
“The invalid string can be precisely geolocated.”
A conventional IP-geolocation lookup requires a valid address. Geolocating `.204` instead would mean looking up a different value.
Frequently asked questions
What is the maximum number allowed in an IPv4 octet?
The maximum is `255`. Each of the four octets can range from `0` to `255`.
Is 111.90.150.2044 a real server address?
Not as a standard IPv4 address in the form shown. Its final component makes the string invalid.
Is 111.90.150.204 the same thing?
No. `111.90.150.204` is a different, valid IPv4 address. There is no confirmed basis for silently removing the final `4`.
Should I block it if I see it in a security log?
Verify the original event first. Since the value is malformed, determine the genuine source or destination address before creating a rule that could affect an unrelated host or subnet.
Conclusion
The useful fact about `111.90.150.2044` is technical rather than mysterious: it is not a valid IPv4 address because `2044` is outside the permitted 0–255 octet range.
The separate address `111.90.150.204` and port `2044` are both real networking values, but neither can be assumed to be the intended meaning of the malformed string. If it appears in an actual log or security record, the safest interpretation comes from preserving the original entry and examining its surrounding fields rather than correcting, geolocating or attributing it by resemblance.
