Well... yes and no. Some values are multiple machine words, pushed onto the stack.
Some of these (such as double-words) have language-defined representations. (They're always stored with the low word at the lower address, regardless of your machine endianness or, as far as I can tell, whether your stack is growing up or down. Which means that on some platforms the low word is pushed first, and on others the high word first. This shouldn't matter, because you should be using the dword words to manipulate them, except that it's common practice to assemble and disassemble dwords manually.)
Some have implementation-defined implementation-defined representations. For example, the various bits of state that the control flow words push onto the return stack. You don't know how big any of these are, so accessing the return stack from inside loops is basically impossible.
And some are just weird. Floating-point numbers live on their own stack. Except not necessarily; the implementation is allowed to store them on the data stack. So you can't use NIP TUCK OVER PICK etc because you don't know the layout of your stack.
Basically, at every point, you have to know the type of the values on your stack so you can pick the right word (DROP vs 2DROP vs FDROP) to operate on the stack... and if you get it wrong, you get stack corruption and horrible, hard-to-debug crashes.
tl;dr: Forth is typed. Forth is very typed. Forth just doesn't check types.
That's one definition of "typed", but not a very useful one. By that definition _everything_ is typed. That's an interesting metaphysics discussion worth having, but not relevant to explaining Forth to a C programmer.
Vanilla Forth values do not have runtime type information (such as class pointers or discriminator tags) nor does a traditional forth compiler have compile time type information (such as an abstracted understanding of the state of the stack at any given point of execution).
Meanwhile, Factor, a modern stack language has both: SmallTalk-style object-oriented class pointers on every value, and a compile-time stack-effect checker. Factor values have a Lisp-like dynamic typing discipline. That is to say "uni-typed" as "dynamic", or a discriminated union.
Wouldn't that make it terrible for working on problems which deal with data which maps to machine words very poorly (ie practically every problem non-OS developers face)?
